Le 05/03/2016 10:31, Larry Hastings a écrit :
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.
Agreed. However, if the kind of performance problem you have is the kind where you have a couple well-known critical paths, it is possible to speed that up significantly using either raw C, or Cython, or even Numba in some cases as Stefan mentions. Not to mention of course any third-party library that might already have done the work for you (in the field of scientific computing, there are many of them).
For the other kind of Python performance problem, where the slowness comes from a long convoluted critical path crossing a lot of high-level interfaces, then PyPy is currently king and I expect it to remain it for a long time.
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.
This is all overlooking the fact that the C API isn't merely used for low-level binding to third-party C libraries (something which Cython allows you to do without writing C code, btw, and AFAIU Cython kindof has a PyPy backend?). The C API allows you to write extension types, or accces interpreter structures for other purposes. Those uses aren't catered for by cffi, by design.
Regards
Antoine.