v0.3.17

The first capture in a process is about 3.2× faster — roughly 1290 ms down to 420 ms. Captures after the first are unchanged, as is the output.

round	0.3.17	0.3.16
1	482 ms	1255 ms
2	372 ms	1300 ms
3	413 ms	1307 ms

What was slow

The cost was first contact with each application. The first accessibility call to a process takes around 8 ms, because the connection has to be established; later calls to the same process take microseconds. Profiling a cold capture put 1.198 s in GetAttribute across 146 calls.

Two functions asked every one of the ~50 running applications in turn:

menu bar extras discovery   0.80 s   asks each app for its extras menu bar
listing windows             0.46 s   asks each app for name, status, main window

Both now probe concurrently. Discovery measured on its own went from 1057–1312 ms to 209–231 ms.

Changed

• Applications are probed concurrently on a cold capture. Warm captures remain at around 75 ms, and the output is identical — the same windows and the same nodes, compared entry by entry in both directions.

Notes

Parallelism is not a general win in this codebase, and it is worth recording why this instance is different. An earlier experiment overlapped attribute fetches inside a single application and measured slower — 67.7 ms against 83.0 ms — because one accessibility server answers requests serially, so nothing overlapped while the machinery still cost real work.

These loops address separate processes, which do respond at the same time. It is the same reason scanning several applications for nodes has always been threaded. The distinction is whether the requests share a server, not whether there are many of them.

Most of what this recovers is cost introduced by the menu bar extras feature in 0.3.16, whose discovery step was the single largest contributor to the cold path.

Full Changelog: v0.3.16...v0.3.17