← 返回首页
gh-104144: Optimize gather to finish eagerly when all futures complete eagerly by itamaro · Pull Request #104138 · python/cpython · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

gh-104144: Optimize gather to finish eagerly when all futures complete eagerly#104138

Merged
kumaraditya303 merged 8 commits into
python:mainfrom
itamaro:asyncio-skip-gathering-future
May 6, 2023
Merged

gh-104144: Optimize gather to finish eagerly when all futures complete eagerly#104138
kumaraditya303 merged 8 commits into
python:mainfrom
itamaro:asyncio-skip-gathering-future

Conversation

itamaro commented May 3, 2023
edited
Loading

Copy link
Copy Markdown
Contributor

gh-97696 introduced eager tasks factory, which speeds up some async-heavy workloads by up to 50% when opted in.

installing the eager tasks factory applies out-of-the-box when gathering futures (asyncio.gather(...)), e.g.:

asyncio.get_event_loop().set_task_factory(asyncio.eager_task_factory) await asyncio.gather(coro1, coro2, coro3)

coro{1,2,3} will eagerly execute the first step, and potentially complete without scheduling to the event loop if the coros don't block.

the implementation of eager uses callbacks internally that end up getting scheduled to the event loop even if all the futures were able to finish synchronously, and blocking the coroutine in which gather() was awaited, preventing the task from completing eagerly even if otherwise it could.

applications that use multiple levels of nested gathers can benefit significantly from eagerly completing multiple levels without blocking, as implemented in this PR by skipping scheduling done callbacks for futures that are already done (e.g. finished eagerly).

Benchmarks

this makes the async pyperformance benchmarks up to 3x faster (!!), using a patch to pyperformance that adds "eager" flavors

3.12-base.20230503.async.4.json =============================== Performance version: 1.0.7 Python version: 3.12.0a7+ (64-bit) revision da1980afcb Report on Linux-5.15.0-1033-aws-x86_64-with-glibc2.31 Number of logical CPUs: 72 Start date: 2023-05-03 23:27:23.329046 End date: 2023-05-03 23:46:37.706326 3.12-nogf.20230503.async.2.json =============================== Performance version: 1.0.7 Python version: 3.12.0a7+ (64-bit) revision 5397cd9f62 Report on Linux-5.15.0-1033-aws-x86_64-with-glibc2.31 Number of logical CPUs: 72 Start date: 2023-05-03 23:05:45.011427 End date: 2023-05-03 23:22:44.908094 +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | Benchmark | 3.12-base.20230503.async.4.json | 3.12-nogf.20230503.async.2.json | Change | Significance | +===============================+=================================+=================================+==============+========================+ | async_tree_cpu_io_mixed | 868 ms | 859 ms | 1.01x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager | 391 ms | 129 ms | 3.03x faster | Significant (t=209.74) | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager_cpu_io_mixed | 756 ms | 490 ms | 1.54x faster | Significant (t=167.41) | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager_io | 1.51 sec | 1.50 sec | 1.00x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager_memoization | 595 ms | 314 ms | 1.89x faster | Significant (t=70.25) | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_io | 1.39 sec | 1.40 sec | 1.00x slower | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_memoization | 677 ms | 683 ms | 1.01x slower | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_none | 575 ms | 574 ms | 1.00x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+

itamaro force-pushed the asyncio-skip-gathering-future branch from 4a5d42c to b3e479a Compare May 3, 2023 20:57
itamaro changed the title gh-NNNN: Skip creating GatheringFuture if all futures finished eagerly gh-104144: Skip creating GatheringFuture if all futures finished eagerly May 3, 2023
itamaro marked this pull request as ready for review May 3, 2023 23:52

carljm left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

This looks pretty straightforward and reasonable to me, but would prefer for asyncio experts to take a look.

Comment thread Misc/NEWS.d/next/Library/2023-05-03-16-50-24.gh-issue-104144.yNkjL8.rst Outdated Show resolved Hide resolved
Co-authored-by: Carl Meyer <carl@oddbird.net>

jbower-fb left a comment
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

If you look at gather._done_callback() you'll see it has a bunch of logic which gets executed at the moment all the futures have finished (starting from if nfinished == nfuts: on line 781). If all args can complete eagerly then this will be executed eagerly too.

This might have a few issues:

  • At this point outer will be None and this will cause trouble on line 803. (Maybe I missed something because I'm surprised this hasn't come up yet).
  • Handling for futures that were cancelled during eager execution is processed but the results discarded.
  • We inefficiently create a result list which we discard and then repeat when creating the eagerly completed future result.

Fortunately, I think an easy fix is to move creation of the eager result future to before the argument processing loop. See my in-line comments for specifics.

I'm not 100% sure how this will affect the issue described in bpo-46672, but it has a test so we'll see.

Comment thread Lib/asyncio/tasks.py Outdated Show resolved Hide resolved
Comment thread Lib/asyncio/tasks.py Outdated Show resolved Hide resolved
Comment thread Lib/asyncio/tasks.py Outdated Show resolved Hide resolved
Comment thread Lib/asyncio/tasks.py Outdated Show resolved Hide resolved
Comment thread Lib/asyncio/tasks.py Outdated Show resolved Hide resolved
Comment thread Lib/asyncio/tasks.py Outdated
outer = futures.Future(loop=loop)
outer.set_result([c.result for c in children])
else:
outer = _GatheringFuture(children, loop=loop)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment
Suggested change
outer = _GatheringFuture(children, loop=loop)
outer.__self_log_traceback = False
outer = _GatheringFuture(children, loop=loop)

carljm commented May 5, 2023

Copy link
Copy Markdown
Member

The title no longer accurately describes the updated PR, since the _GatheringFuture is always created.

itamaro commented May 5, 2023

Copy link
Copy Markdown
Contributor Author

thanks for the review @jbower-fb !

I pushed a new version of the PR based on your suggestions, but not identical.
summary of my changes:

  • instead of immediately calling the done callbacks for eagerly completed futures in the loop, I add them to a list and call their callbacks only at the end, after creating the outer future
  • this helps because now outer is defined the same way, and the children list is fully populated, which is also important because the done callback uses the children list
  • I always create a GatheringFuture so I get the same cancellation treatment, but it will still finish eagerly if all futures completed eagerly thanks to the last done callback right before returning
  • there shouldn't be any issues with bpo-46672 since outer looks the same as before

itamaro changed the title gh-104144: Skip creating GatheringFuture if all futures finished eagerly gh-104144: Optimize gather to finish eagerly when all futures complete eagerly May 5, 2023

itamaro commented May 5, 2023

Copy link
Copy Markdown
Contributor Author

The title no longer accurately describes the updated PR, since the _GatheringFuture is always created.

thanks, I updated the title!

gvanrossum left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

LGTM, will fix the typo. Maybe @carljm can merge when you all are agreed on this. Nice fix!

Comment thread Misc/NEWS.d/next/Library/2023-05-03-16-50-24.gh-issue-104144.yNkjL8.rst Outdated Show resolved Hide resolved
AlexWaygood added the performance Performance or resource usage label May 6, 2023

Copy link
Copy Markdown
Member

PS. In general there's no need to click the "Update branch" button (or otherwise merge main back into the PR) unless there are fixes/changes that might affect the PR (e.g. if touching the same file).

kumaraditya303 enabled auto-merge (squash) May 6, 2023 14:55
kumaraditya303 merged commit 263abd3 into python:main May 6, 2023
itamaro deleted the asyncio-skip-gathering-future branch May 7, 2023 22:16
jbower-fb pushed a commit to jbower-fb/cpython that referenced this pull request May 8, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance Performance or resource usage topic-asyncio

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

Footer

© 2026 GitHub, Inc.