-
Notifications
You must be signed in to change notification settings - Fork 0
Add conditional GIL release based on data size threshold #11
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
Conversation
Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
Introduces GIL_RELEASE_THRESHOLD_FRAMES (1000) to only release the GIL when the data size is large enough that resampling work dominates the GIL release/acquire overhead (~1-5 µs). This improves single-threaded performance for small data sizes while maintaining multi-threading benefits for large data sizes. - Resampler.process(): conditional GIL release - CallbackResampler.read(): conditional GIL release - resample(): conditional GIL release - Added tests for conditional GIL release behavior - Updated .gitignore to exclude compiled extensions Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
Use lambdas to extract the common resampling logic, making the conditional GIL release pattern more maintainable. Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
|
@copilot Look deeper - is there a better way to handle this, or to resolve or otherwise manage this issue. |
Instead of using only a fixed threshold, users can now explicitly control GIL release behavior via a new release_gil parameter: - None or "auto" (default): Release GIL only for large data (>= 1000 frames) - True: Always release GIL (best for multi-threaded applications) - False: Never release GIL (best for single-threaded, small data) This provides better control compared to the previous threshold-only approach: - Single-threaded applications can use release_gil=False to avoid overhead - Multi-threaded applications can use release_gil=True for maximum parallelism - Default "auto" mode balances both use cases Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
Investigated deeper and implemented a better solution in commit 3f0df5f. Instead of only using a fixed threshold, users now have explicit control via a # Default "auto" mode (threshold-based)
samplerate.resample(data, ratio)
# Force GIL release for multi-threaded apps
samplerate.resample(data, ratio, release_gil=True)
# Disable GIL release for single-threaded, small data
samplerate.resample(data, ratio, release_gil=False)This approach:
|
|
@copilot Update the documentation with this new parameter |
Added a new "Multi-threading and GIL Control" section explaining: - The release_gil parameter and its three modes (None/auto, True, False) - When to use each mode for optimal performance - Examples for resample(), Resampler.process(), and CallbackResampler.read() Co-authored-by: shauneccles <21007065+shauneccles@users.noreply.github.com>
release_gilparameter for explicit controlSummary
This PR addresses the issue where releasing the GIL during resampling operations added overhead that impaired single-threaded performance for small data sizes.
Root Cause
The GIL release/acquire overhead (~1-5 µs) was significant for small data sizes where the actual resampling work only took 20-100 µs.
Solution
Added a new
release_gilparameter to all resampling methods that gives users explicit control:Results
Original prompt
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.