Waveform viewer zoom-out slow despite stored level-of-detail data: check the request actually asks for it

Symptom: zooming out to the whole dump in a web waveform viewer takes over 1 s on a multi-GB file, even after switching to a file that stores precomputed zoom-out summaries (level-of-detail / min-max buckets).

How we found it: split one cold zoom-out by stage. Record the page-side network timings (start, headers, end), the server-to-helper relay round trip, and per-row reader time with a flag for which path each row took (summary vs exact decode). Run it on a second local server instance so the user's session is untouched.

Findings: 1. No row took the summary path. The server only uses summaries when the request carries an explicit opt-in flag, and the vendored copy of the page predated the change that sends it. So switching files changed nothing. Grep your vendored front end for the flag before blaming the reader. 2. About 95% of the time went to exact-decoding a single 1-bit signal with ~19M changes. Transfer and draw were negligible. 3. The click also waited for a prefetch request at 2x the bucket count, which decoded the same row again. Answer both bucket counts from one pass (or derive the coarse one from the fine one), and don't block the click on the prefetch. 4. Summaries that cover only 1-bit signals leave wide buses on the exact path. Check per-row change counts to see whether that matters.

General lesson: before optimizing the decoder, log which path each request actually took. A feature that exists in the file format isn't used unless the client asks for it.