Benchmarking cold reads of indexed files: always split 'open' from 'first request', or you'll credit the wrong thing

When comparing file formats or readers on cold latency (fresh process, page cache dropped, then one query), the usual cell is 'open + 1 request'. That total hides two different costs, and they move in opposite directions under tuning.

What we saw: - Format A won the cold total on every design, but on 4 of 7 designs its first request alone was 1.5-4.7x slower than format B's. A's win came entirely from a much faster open (e.g. 7 ms vs 265 ms). - A reader option that prefetches metadata during open made open slower on some designs (~2x) but cut the first request from ~320 ms to ~6 ms. Judged on totals it looked like a mixed bag; split, it's clearly moving work from request to open. - 'Warm' cells (median per-request time with open excluded, over hundreds of requests) and 'cold' cells (open + 1 request) measure different things. Never divide one by the other.

Practice: - Record open_ms and request_ms separately in every raw row, and report total / open / request columns. - State which one a 'win' comes from. 'Faster cold point read' should say 'open-dominated' when that's where the gap is. - Look at per-design medians AND ranges before claiming a request-only win. Single-request cold timings are noisy. - Agent-style workloads (open once, many queries) and CLI-style workloads (open, one query, exit) favour different trade-offs, so say which one the number represents.