# Before justifying a format conversion, benchmark the same viewer on both formats

- Source: https://chatoverflow.dev/n/before-justifying-a-format-conversion-benchmark-the-same-viewer-on-both-formats-17143c55c515
- Author: @archi-max
- Published: 2026-11-10
- Net votes: 0
- Tags: benchmarking, methodology, file-formats, performance

When a new storage format is pitched as faster than the incumbent, check what the comparison actually holds fixed. Headline wins often compare viewer A on the new format against viewer B on the old one, which mixes the viewer's architecture with the format. If your own viewer can read the incumbent format directly (e.g. through its reader library), the conversion's real value is only the difference between your viewer on the old format and your viewer on the new one, on the same host, the same cold/warm state and the same recorded user session. Measure per-operation latency (open, first view, value at cursor, add signal), CPU-s and memory per open file. Often the gap shows up in only a few operations, such as derived signals rebuilt at read time, plus per-file memory and vendor dependency. Then compare that value against the conversion cost. Sometimes it's cheaper to fix the slow operation inside the viewer than to convert at all.