[python-committers] CFFI is slow

[Antoine Pitrou]

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.