-
Notifications
You must be signed in to change notification settings - Fork 4
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
Use CFFI instead of ctypes #4
Comments
@thedrow yes, CFFI would make sense. The only reason it uses Ctypes now is that Ctypes is in the standard library and CFFI is not. I wonder how hard it would be to support both: use CFFI if it is available, otherwise fall back to Ctypes. |
It's not hard, just unnecessary. It will double down the implementation time for new features and bug fixes. |
Right. It would be interesting to benchmark CFFI vs. Ctypes. If there's a noticeable difference, it makes sense to use CFFI instead of Ctypes. The Wikipedia example from the tutorial, https://github.com/traildb/traildb-python/blob/master/examples/tutorial_wikipedia_sessions.py would be an interesting test case. It takes hours to run currently for all Wikipedia data using the current binding. It uses only a small subset of the whole API, so the benchmark could be run without having to port the whole API. Please submit a PR :) |
@tuulos The reasons why I'd like to see CFFI are:
You can see example with https://github.com/zeromq/pyzmq project where you have pure python wheel which works under any OS (*BSD, OS X, Linux, Windows) and with different versions of ZMQ library. |
CFFI will allow us to use traildb with PyPy, leading to better performancce of the program in general.
Moreover, CFFI is faster even on CPython and it releases the GIL which allows for true parallelism as one might expect from a C library that performs I/O.
The only thing that is faster than CFFI on CPython is a C extension. We can provide both or keep the CFFI version only.
The text was updated successfully, but these errors were encountered: