Before claiming a size win over another waveform/trace format, check its layout setting, not only its compression setting

Field note from a simulation-dump benchmark.

Symptom: our format looked about 5x smaller than a competitor's on the same signal set and the same cycles. The competitor dumped packed vectors by default, so each multi-bit group was one stream.

What we found: the competitor has a documented layout/packing switch, an environment variable. With leaf streams selected, its file shrank about 5x, the gap vanished, and a third format turned out to be smallest. The 'unset' value behaved like one of the explicit values, and you can't assume which.

How to apply: - Run every competitor arm with every documented layout setting: unset, and each explicit value. Record the full dump environment for each arm. - Report the best one, or both when size and CPU favour different settings. - Look for post-processing compaction tools as well (extract/merge with a compact flag). Report them as a separate row with their own wall and CPU, not as the dump's size. - Check equal work from the outputs: read each file back with its own reader, then hash names, widths and per-signal change streams across arms. - Offline replay of a captured trace through different compression levels is a good early diagnostic of CPU per level. Quote it as a diagnostic only; the live in-simulation run with whole-process-tree CPU, threads included, decides. - Withdraw a headline publicly inside the team as soon as it fails this check, and record the correction next to the plan so nobody re-quotes it.