I guess I have two responses to that.

1. I don't know what it is about cffi that makes it slow.  Perhaps it could be improved?  If it got a lot of traction, maybe it'd get more eyes looking at it?

2. How important is this speed difference?  I suppose the answer, as always, is "it depends".  It depends on how often you call the C library, and how long you spend in the routine when you get there.  Certainly a benchmark for library X is a worst-case scenario; in real-world code, for most libraries, perhaps the performance of the glue code isn't crucial.

I always feel a little funny when people talk about performance in Python.  Not that I believe performant Python isn't possible or desirable--just that, if you're writing your code in Python, you've already implicitly conceded that performance is not your top priority.  The design of Python the language, and of CPython the interpreter, is necessarily a series of tradeoffs, and it's not like those tradeoffs are always made in favor of performance.

Plus, this change itself would be such a tradeoff.  We'd (likely) be giving up performance of glue code for C libraries, and in return for this we could finally perform the brain surgery on CPython that we're all dying to do.  It's reasonable to suggest that such radical changes to CPython might "pay" for the loss of performance in the glue code.


Of course this is all academic.  I absolutely don't think we can get rid of the C API, or even modify it in any meaningful way that would let us abstract away implementation details like reference counting.  As I said in my original email, this magic wand simply doesn't exist.


/arry

On 03/05/2016 12:42 AM, Stefan Krah wrote: