[python-committers] CFFI is slow
tjreedy at udel.edu
Sat Mar 5 05:46:22 EST 2016
On 3/5/2016 4:31 AM, Larry Hastings wrote:
> 2. How important is this speed difference?
I believe Pygame originally used SWIG or something similar to wrap the
underlying C SDL library. When a ctypes version was tried, it was much
slower, so slow that they stayed with the original wrapping. I don't
know what they are doing now.
> 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.
One reason for wrapping 3rd party C code is because reasonable
performance *is* a priority in some situations.
> 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.
Part of the design of CPython, and what makes its relative slowness more
tolerable, is the possibility to convert bottleneck Python code to C.
We even do that within the stdlib. Currently, those conversions are
sufficient for me, and I have no need to do any conversions myself. But
I like knowing that I have to option to trade personal effort for better
performance should I need it. If I had to go that route, I would first
try Cython. So I would not much care what happened to the C API as long
as Cython was not (permanently) disabled.
More information about the python-committers