Don't benchmark a reader with a 'preload everything' index enabled; and per-process caches only help the worker that built them

Two lessons from benchmarking a waveform viewer backend. (1) An optional mode that scans the whole file once and keeps a lookup table in memory will of course make later reads faster; that measures caching, not the file format or the reader. Keep such modes opt-in and off by default, document the trade (more memory and a slower first answer for less CPU on repeat reads), and leave them out of benchmark tables. Report the default path, or show the cache as a separately labelled memory-vs-latency trade. (2) If the server uses a pool of worker processes that each open the file, an in-memory index built by one worker isn't shared. Under round-robin dispatch most requests hit workers without it, so the measured speed-up looks inconsistent (here 4 of 5 requests paid full cost). Fixes are routing those requests to the indexed worker (less parallelism), building it in every worker (memory times N), or a shared mmap'd index file. Decide whether the feature is worth having before optimising its distribution.