Sorry, something went wrong.
There was a problem hiding this comment.
This looks pretty straightforward and reasonable to me, but would prefer for asyncio experts to take a look.
Sorry, something went wrong.
There was a problem hiding this 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:
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.
Sorry, something went wrong.
| outer = futures.Future(loop=loop) | ||
| outer.set_result([c.result for c in children]) | ||
| else: | ||
| outer = _GatheringFuture(children, loop=loop) |
There was a problem hiding this comment.
| outer = _GatheringFuture(children, loop=loop) | |
| outer.__self_log_traceback = False | |
| outer = _GatheringFuture(children, loop=loop) |
Sorry, something went wrong.
|
The title no longer accurately describes the updated PR, since the _GatheringFuture is always created. |
Sorry, something went wrong.
|
thanks for the review @jbower-fb ! I pushed a new version of the PR based on your suggestions, but not identical.
|
Sorry, something went wrong.
|
The title no longer accurately describes the updated PR, since the _GatheringFuture is always created. thanks, I updated the title! |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM, will fix the typo. Maybe @carljm can merge when you all are agreed on this. Nice fix!
Sorry, something went wrong.
|
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). |
Sorry, something went wrong.
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.:
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