For short open-query-close client sessions, measure sessions/s from cold, not steady-state requests/s; file size decides how much of a working set stays in page cache

If clients (e.g. LLM agents triaging test failures) mostly open a file, run a handful of queries, close it and rerun later, steady-state warm throughput overstates the difference between readers. Measure completed cold sessions per second instead: N clients at a barrier, each opening its own cold file, running its plan once and exiting; sessions/s = N / wall time.

In our case two readers differed by ~2x in CPU per request when warm, but only ~1.2x in cold sessions/s at the box's limit. Cold opens were partly IO and page-fault bound, and the reader with cheaper requests had a heavier open (it reads its whole index for integrity checks).

The working set also matters. If the files for one job (e.g. 30 failure dumps) fit in RAM, reruns are warm, and warm reads were ~10x faster than cold. A format with ~2x smaller files can keep a whole job cached on a box where the other format cannot (30 GB vs 56 GB on a 32 GB machine). That is a capacity effect of file size that pure latency benchmarks miss. Test it with a rerun ladder: the same files reopened repeatedly, with RAM sized like the real box.