gh-104144: Skip scheduling a done callback if a TaskGroup task completes eagerly

[itamaro]

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 creating tasks as part of a TaskGroup, e.g.:

asyncio.get_event_loop().set_task_factory(asyncio.eager_task_factory) async with asyncio.TaskGroup() as tg: tg.create_task(coro1) tg.create_task(coro2) tg.create_task(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 TaskGroup uses callbacks internally that end up getting scheduled to the event loop even if all the tasks were able to finish synchronously, and blocking the coroutine in which TaskGroup() was awaited, preventing the task from completing eagerly even if otherwise it could.

applications that use multiple levels of nested TaskGroups can benefit significantly from eagerly completing multiple levels without blocking, as implemented in this PR by skipping scheduling the done callback if the future is done.

Benchmarks

this makes the async pyperformance benchmarks up to 4x faster (!!), using a patch to pyperformance that adds "eager" flavors and uses TaskGroups instead of gather

3.12-base.20230503.async.3.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 22:18:14.628900 End date: 2023-05-03 22:36:35.397630 3.12-tgcb.20230503.async.3.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 22:38:45.960219 End date: 2023-05-03 22:54:49.008951 +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | Benchmark | 3.12-base.20230503.async.3.json | 3.12-tgcb.20230503.async.3.json | Change | Significance | +===============================+=================================+=================================+==============+========================+ | async_tree_cpu_io_mixed | 843 ms | 827 ms | 1.02x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager | 383 ms | 92.9 ms | 4.12x faster | Significant (t=189.26) | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager_cpu_io_mixed | 708 ms | 412 ms | 1.72x faster | Significant (t=180.43) | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager_io | 1.40 sec | 1.39 sec | 1.01x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_eager_memoization | 515 ms | 232 ms | 2.22x faster | Significant (t=183.24) | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_io | 1.37 sec | 1.35 sec | 1.01x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_memoization | 644 ms | 634 ms | 1.01x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ | async_tree_none | 517 ms | 508 ms | 1.02x faster | Not significant | +-------------------------------+---------------------------------+---------------------------------+--------------+------------------------+ 

• Issue: Leverage eager tasks to optimize asyncio gather & TaskGroups further #104144

[gvanrossum]

LGTM.

How sure are you that skipping the set-name call if name is None is always correct? (It seems fine to me, but in theory some 3rd party task implementation could do other stuff there.)

[itamaro]

How sure are you that skipping the set-name call if name is None is always correct? (It seems fine to me, but in theory some 3rd party task implementation could do other stuff there.)

I don't know about all possible 3p task implementations. At least looking at uvloop, it seems it uses asyncio.Task directly.
the asyncio Task.set_name returns immediately if name is NULL, so just saving the function call is a pretty minor optimization that we can probably revert with no noticeable regression (I can measure it). If this will make interop with 3p Task implementations better I think it's worth it.

[gvanrossum]

I don't think it will be measurable -- it looks to be a very minor part of creating a task (even more so with gh-103767). It just is one more thing we'd have to put in what's new (and it's not covered by the PR title :-).

[itamaro]

agreed, let me revert that part!

[kumaraditya303]

Hmm actually the scheduling is skipped on a per task basis rather than when all tasks finish without blocking.

[itamaro]

I have a fix in itamaro@ac1ee82 (PR depends on gh-104251 first)