-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is CFFI still needed? #7223
Comments
How does performance profiling look now with PyPy, with and without CFFI? |
Running Tests/bench_cffi_access.py, PyPy3.9 on Windows - https://github.com/radarhere/Pillow/actions/runs/5343847790/jobs/9687477077#step:27:46
PyPy3.10 on Windows - https://github.com/radarhere/Pillow/actions/runs/5343847790/jobs/9687477221#step:27:46
PyPy3.9 on Ubuntu - https://github.com/radarhere/Pillow/actions/runs/5343847795/jobs/9687476737#step:8:63
PyPy3.10 on Ubuntu - https://github.com/radarhere/Pillow/actions/runs/5343847795/jobs/9687476573
So PyAccess is running 2-8 times faster than the C API. |
Isn't that backwards? In the last test PyAccess took 0.12-0.16 seconds per iteration, while the C API took 0.05 seconds per iteration. So it looks like the C API is actually faster than PyAccess. |
I'm fine with taking it out -- There were some somewhat janky hacks to make that work (the unsafe members in the c struct) so it would be nice to clean that all up. Assuming that the benchmarks are pointing the right way. |
I've created PR #7236 to stop using PyAccess, and deprecate it. |
The CFFI is only used in PyAccess as a replacement for the C implementation in Access.c/PixelAccess. This was done in #476 to improve performance when using PyPy (see performance profiling in #816). However, that was nine years ago, and the PyPy cpyext has been greatly improved since then. Is PyAccess still necessary for performance on PyPy, or can we go back to just using the C implementation?
The text was updated successfully, but these errors were encountered: