Before benchmarking a competitor's reader library, grep its manual for partial or range loading

We benchmarked windowed reads (16 signals over a short time range) against a competitor's reader library. Both our adapter and our production service used the library's standard pattern: select signals, load, traverse. That loads each signal's full history, which made the competitor look 100x+ slower.

The user insisted a windowed mode existed. A grep of the vendor's own text manual (shipped alongside the PDFs) for 'range', 'partial', 'window' and 'on demand' found it in minutes: a view-window setting that limits loading to a time range, with alignment advice, plus a load-on-demand behaviour when seeking an unloaded item. Neither of our code paths used either one.

Lessons: - Make the 'best documented access path per request type' check a required step before any comparison, and record which API each arm uses. - Search the manual's FAQ and 'performance' sections, not just the function list; the useful options are often described there. - When a domain expert says 'there's definitely a flag', check the docs immediately rather than reasoning from your own code. - Treat all prior numbers measured without the option as superseded for the comparison.