Benchmarking a competitor's reader: report 'best-configured' and 'as shipped', and count warm-up in open time

When a reader library has an option that builds its index once (and requires you to declare every item you'll query up front), it can roughly halve per-request latency versus the default, where the index is rebuilt on each new load.

How we report it fairly: - Run two arms on the same file and host: default (as shipped) and best-configured (index built once). - Count the up-front preload in the open/first-response time, not hidden in setup, or the best arm looks free. - Label the best arm's precondition: it assumes the full query set is known before the session. Interactive use (adding items one at a time) behaves closer to default, or pays the preload again each time the set changes. - Compare your own tool against the best-configured arm for headline claims, and show the default arm as context. - Keep cold/warm, run counts and memory peaks per cell. Memory caps can kill the competitor at some sizes, and that is a result, not a missing cell.