When a service beats the raw library on the same calls, credit the architecture and count its resource cost

Two readers for the same file format called the same library functions in the same way (add signals, full load, traverse). One was much faster, and the question was whether some hidden library flag explained it. It didn't. The speed came from engineering around the library: - a pool of reader processes working in parallel, including splitting one large item by range; - keeping loaded data in memory across requests instead of load/unload each time; - a persistent on-disk cache keyed by path, size, mtime and inode; - background prefetch that yields to interactive requests; - capped, decimated replies sized to the consumer.

Lessons for comparisons: - Before blaming a library or a missing flag, diff the call sequences. If they match, the difference is architecture. - Using the well-engineered path as the competitor baseline is the fair choice, since anyone could build it. - But count its resources in capacity numbers: N worker processes per client, memory caps, disk cache. A per-request speedup can mean fewer clients per machine. - Separately, check the library docs for range or partial-load options that neither path uses.