[asvetlov]

Run callbacks that are scheduled during an event loop iteration eagerly, within a small budget, instead of always waiting for the next I/O poll. This removes one select()/epoll_wait() call per hop in code that resolves futures or wakes tasks in chains.

• New asyncio.EventLoopSettings(eager_max_time, eager_max_callbacks) and loop.get_settings() / loop.set_settings(). The defaults are 100 µs and 100 callbacks; eager_max_time=0 turns eager processing off.
• Eager processing ends early on asyncio.sleep(0), which still guarantees an I/O poll, and on loop.stop(), which keeps its documented "current batch only" behaviour.
• Callbacks still run in first-in, first-out order. Only the number of I/O polls changes.

Benchmarks (release build, script): a call_soon() chain is 38% faster, Queue ping-pong 25% faster, and a task awaiting a child task 33% faster. Servers with many connections are unchanged. While a long run of callbacks keeps going, timers and I/O can be delayed by up to about 100–200 µs.

A few tests that assumed "one task hop = one I/O poll" were adjusted.

• Issue: asyncio: run newly scheduled callbacks eagerly before polling for I/O #160760

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #35605654 | 📁 Comparing db878e0 against main (085d366)

  🔍 Preview build  

113 files changed · ± 113 modified

± Modified

• builtins/exceptions.html
• builtins/functions.html
• builtins/stdtypes.html
• c-api/bool.html
• c-api/buffer.html
• c-api/bytes.html
• c-api/code.html
• c-api/codec.html
• c-api/datetime.html
• c-api/extension-modules.html
• and 103 more...

[YvesDup]

Sorry, but I don't see in any tests, assertion on the _eager_state attribute used as a counter even it is a private attribute ? Maybe I missed something.

[asvetlov]

Right, no test asserts the value of _eager_state directly. That's on purpose: it's a private detail, so the tests check what it controls: which callbacks run in which iteration, what is left in _ready, and how many times the selector is polled. To make sure this covers the counter, I tried storing no count, a count one too high and a count one too low; each change makes test_run_until_complete_after_eager_limit fail, and most of them also make some of the test_run_forever_stop_* tests fail.

[YvesDup]

That sounds good to me.