I'm not familiar enough to know whether these are okay to do even when not debugging, particularly the _current_handle assignment.

The report should be in debug mode only, sure.
Two timer calls per callback are not free.

Is there a better way of detecting a stall? I did a quick bit of bechmarking and a raw, non-lookup'd call to time.time() or time.monotonic() is about as fast as you can get (~50ns), on-par with invoking lambda: None or def foo(): pass.

A 100ns overhead per callback leaves a lot of breathing room.

Why all three arguments (handle, formatted handle, and loop) are passed?
I suspect the only handle is enough for a low-level tool.

Agreed. It might also help to have an event at the point where a handle is created, so there's another event to correlate with, but you certainly don't want to be eagerly formatting anything.

Assume the audit hook is merely print to a log that's going to be interpreted by a human (or a separate machine). It's not an opportunity for an application to change its behaviour.

Interesting.
If we add two events (handle started and handle finished) asyncio doesn't need to calculate the handle callback execution time.
The audit hook can do it itself if needed.
Also, it means that both hooks can be called even in non-debug mode.
The calling is cheap, analyzing can be expensive but it is not an asyncio problem.

Calculating the handle callback execution time seems really quite cheap, unless I'm missing something. In fact it seems it would be far cheaper to calculate the time difference and invoke an audit hook once rather than invoke an audit hook twice:

In [2]: sys.addaudithook(lambda *f: None)
In [3]: a = sys.audit
In [5]: %timeit a("foo")
174 ns ± 1.16 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [7]: m = time.monotonic
In [8]: %timeit m()
60.3 ns ± 1.18 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

People who care about maximum performance won't have any audit hooks (or they'll have native ones, which are considerable quicker than pure Python ones), so it's not a fair the right comparison.

Still, I'd rather audit events be used for unusual/unexpected events rather than tracing. If this is a tight loop operation where 0.1us is important enough for performance to override functionality concerns, then we don't want audit events being raised that frequently. If it's fairly uncommon then may as well do the calculation and only raise relevant events to keep the noise down.

I'd argue that an event loop stall should be both unusual and unexpected. But you're right, I'm not sure audit events are a perfect fit here.

The whole point behind this is that it's hard, or even impossible, to get metrics about event loop stalls in production right now without running your entire app in async debug mode. Which is interesting, because people who care about maximum performance would surely want accurate metrics on stalls whilst being totally adverse to running things in debug mode.

Some way to do something in response to a stall would be ideal. We maybe even don't need an exact time, just an idea that a stall took place and a way to consume that to do custom stuff ™️.

I see different numbers with the fresh main branch:

>>> import timeit
>>> timeit.repeat("sys.audit(1); sys.audit(1)", "import sys")
[0.09353699500206858, 0.07102967600076227, 0.07030134299566271, 0.07094913300534245, 0.06989944599627052]
>>> timeit.repeat("time.monotonic(); time.monotonic()", "import time")
[0.19186055000318447, 0.16878722599358298, 0.16965712599630933, 0.1693656099960208, 0.16873898899939377]

Note: there is no audit hook subscribed.

Looking up the monotonic attribute dominates the benchmark. You get much better speeds by assigning time.monotonic to a local variable once and using that.

I'm using 3.10, so maybe things have changed, but sys.audit(1) throws an exception for me.

I suggest measuring Python 3.11 and the real scenario.
E.g. two loop.time() calls plus one sys.audit() vs two sys.audit() calls.