-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
gh-102024: Reduced _idle_semaphore.release calls #102025
gh-102024: Reduced _idle_semaphore.release calls #102025
Conversation
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
Most changes to Python require a NEWS entry. Please add it using the blurb_it web app or the blurb command-line tool. |
Thanks! One more important thing is missing: benchmarks. |
@sobolevn BTW is there any newcomer |
Added some benchmarks. In my tests there is noticeable boost for submits to one thread. |
@arhadthedev I don't know :( |
_idle_semaphore.release() is called if only work_queue is empty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks good to me. I have this exact same change in some custom thread pool code I use :-)
I'm a little confused by your benchmarking. I'm not sure why you'd expect the only submit case to speed up (and I can't repro a speed up on that case locally), without shutting down the executor. Of course, if you add the shutdown, I can measure a win (though ofc the size of win varies based on task count, task size, thread count).
…res/thread.py Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
🤖 New build scheduled with the buildbot fleet by @hauntsaninja for commit afbdad6 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Reduced _idle_semaphore.release calls in concurrent.futures.thread._worker _idle_semaphore.release() is now only called if only work_queue is empty. --------- (cherry picked from commit 0242e9a) Co-authored-by: Andrii Kuzmin <jack.cvr@gmail.com> Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
GH-104959 is a backport of this pull request to the 3.12 branch. |
…104959) gh-102024: Reduced _idle_semaphore.release calls (GH-102025) Reduced _idle_semaphore.release calls in concurrent.futures.thread._worker _idle_semaphore.release() is now only called if only work_queue is empty. --------- (cherry picked from commit 0242e9a) Co-authored-by: Andrii Kuzmin <jack.cvr@gmail.com> Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
_idle_semaphore.release() is called if only work_queue is empty
Benchmarks:
submit_only:
before:
W=1: 100000 loops, best of 10: 17.6 usec per loop
W=2: 100000 loops, best of 10: 10.5 usec per loop
W=4: 100000 loops, best of 10: 10.5 usec per loop
after:
W=1: 100000 loops, best of 10: 7.42 usec per loop
W=2: 100000 loops, best of 10: 7.5 usec per loop
W=4: 100000 loops, best of 10: 7.5 usec per loop
submit_then_wait:
before:
W=1: 10 loops, best of 10: 110 msec per loop
W=2: 10 loops, best of 10: 100 msec per loop
W=4: 10 loops, best of 10: 114 msec per loop
after:
W=1: 10 loops, best of 10: 85.2 msec per loop
W=2: 10 loops, best of 10: 83.9 msec per loop
W=4: 10 loops, best of 10: 86.5 msec per loop