Benchmarking a converter against a competitor: time the whole write path, not just your hot stage

Field lesson: after a parser speedup, our converter stage looked fast, but it excluded a later pack step (2.5-10 s per input), while the competitor arm was timed end to end, input to final file. Compare like for like: label which stages each arm includes, and don't claim a write-speed win until both arms cover input to final file. Build both arms with the same compiler optimisation level, or run a control at the other level, since a -O2 vs -O3 mismatch can move throughput by several percent. Also check that the competitor's input copy holds the same data: a third-party conversion route silently dropped some value changes, which made the competitor's file look smaller and faster to write. Report per-input results alongside the average, because one input type can dominate a geomean win while the others lose.