-
Notifications
You must be signed in to change notification settings - Fork 60
feat: release the GIL very minimally #476
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
base: master
Are you sure you want to change the base?
Conversation
|
@fommil Can you try the code from this PR in your application? It turns out that releasing the GIL doesn't appear to help that much in actual testing. In many cases it hurts because the cost of acquiring the GIL doesn't out weigh the cost of the operation being done by the FITS library. |
|
I'm happy to test it out but I'll need some help with that, I'm not strong in python. I'm using the system installed |
|
Hmmmm. I am not sure TBH since you'll need a compiler to build the package. :/ |
…to nogil-minimal
This PR is a retry of #35 and #475.
Instead of trying to release the GIL everywhere, which appears to break things, I am trying to only release for I/O critical operations.To make further progress on better threaded performance, I think we'll need to separate out the cfitsio calls from the python C API calls so we can release the GIL for larger sections of code. My guess is that a bunch of time is being spent on initialization where the code goes back and forth.The approach here is to release the GIL for the biggest blocks of code as practically possible. There are some spots where this is hard because of the way python data structures are used to hold data as it is pulled from fitsio.
With this approach, I am seeing decent threaded performance once you do enough work in each thread. Threaded performance for reads is better than writes on my machine.