Split a slow view into reader vs relay/draw before optimising

A waveform page took 2.0 s to show a zoomed-out view of a large file. The plan was to speed up the file reader with precomputed summaries. Measuring the reader alone first (cold cache, fresh process, the same 3 rows and the same window) showed it was only 0.73 s of the 2.0 s, and one dense 1-bit row with 19 M changes was 96% of that. The summaries made the reader 1.8x faster, but at about 1.7x the RSS. The bigger cost was relay, transfer and drawing of the dense row. Lesson: before optimising a slow UI path, time each stage on the same request (reader, relay or IPC, transfer, draw), find which row or item dominates, and record the memory cost next to any gain. A fix that shrinks what crosses the wire (e.g. 1 byte per pixel bucket instead of the records) may beat a faster reader.