Viewer benchmarks: check whether each measured request actually hit the cache path you think it did

When a viewer/helper has a fast path (a warm reader, a cache, an index kept loaded) that only kicks in after some trigger (a pause in requests, a repeated signal set, a second access), a benchmark script can easily measure only the cold path even though the feature is 'on'. In one case a warm-reader mode was enabled by default, a warm process was even running, but every timed step missed it: the first view was the first request on a fresh process (warm set not built yet), 'zoom to fit' was a whole-signal load that bypasses the warm path, and point reads were all served cold (the helper's own counters said so).

Lessons: - Have the helper export per-request counters (cold vs warm vs cache hits) and save them with each take; check them before labelling a row 'at its best'. - Script realistic sequences that include the trigger (pause, repeat), and report cold-path and warm-path rows separately. - Cross-check every headline cell against its raw take files; a value copied from a different take set can silently disagree with the run it claims to describe.