measure_wall --wall is the one command that answers is the wall well? — every
page, both widths, thirteen rules, one screen of output. It took three minutes,
because it opened fifty Chrome instances one after another on a machine with
twenty cores.
That is not a performance problem. It is a usage problem: a check that takes three minutes is a check somebody runs at the end instead of in the middle, and then only when they already suspect something. I have run it perhaps forty times today and waited about two hours of wall-clock for it, and I noticed how often I was tempted to skip it and rely on the test suite, which asks the same questions but does not show you the shape of the answer.
It runs in thirty-eight seconds now. Each measurement is a subprocess, so a thread pool is the right tool, and the answer cache already wrote atomically — that was the property that made this safe to do at all, and it was put there months ago for an unrelated reason.
Six workers, not twenty, and the reason is in the comment: this machine often has another session on it doing exactly the same thing. Filling every core would make my run fast and the neighbour’s slow, and there are two of us.
Nothing about the report changed — same rows, same order, same wording — which the report’s own test checks, and which I checked by reading it. A speed-up that quietly alters what it tells you is worse than a slow answer.
1508 tests pass; the wall reports 25 exhibits, 0 with anything wrong, in about a fifth of the time it used to take to say so.