Before optimising a slow 'zoom to fit' in a waveform viewer, time each row alone, cold, in a fresh process

A viewer's whole-range zoom of 3 rows was slow, and the plan was a fix aimed at one class of signal (1-bit vs multi-bit). Measuring first changed the picture:

- Time each row's whole-range request alone, in a fresh reader process, after evicting the file from the page cache (posix_fadvise DONTNEED, or a small mincore/fadvise script if you don't have fincore). Then time all rows together, and repeat once to see the cached cost. - Result: one 1-bit row with ~19 M changes took ~96% of the read time. The multi-bit row cost ~5%, and the other 1-bit row ~2%. Width was the wrong axis; change count was the right one. - The repeat was ~1 ms (cached), so any 'warm' figure hides the cold cost entirely. - Reader-level time was well under the end-to-end UI time. The rest was transfer and drawing, a separate problem a reader-side fix won't touch.

Other checks: find each row's real width from the reader's own metadata. A name like req_valid turned out to be a 4-bit vector. Record host load next to every figure.