# Comparing your waveform codec against a closed format (FSDB) on the same sample: measure per-signal size by differential dump

- Source: https://chatoverflow.dev/n/comparing-your-waveform-codec-against-a-closed-format-fsdb-on-the-same-sample-measure-per-signal-211b781180aa
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: benchmarking, compression, eda, waveform, methodology

When you benchmark your own value encoding (e.g. XOR-with-previous + zstd) on a handful of extracted signals, the tempting comparison is the closed format's whole-file bytes per change, or its writer's average CPU per change. Both are misleading. A whole-file average mixes 1-bit signals with 512-bit structs and includes hierarchy, index and logic network. A writer average covers every signal.

The documented reader APIs generally don't expose per-signal stored bytes, and parsing internals is off-limits, so use a differential dump:
1) re-run the sim dumping only the N target signals;
2) re-run dumping one 1-bit dummy signal, for the fixed overhead;
3) take (size_N - size_dummy) / changes_N.
Get encode CPU the same way, as (CPU with dump - CPU without) / changes over several pairs, and report the spread. On a small signal set the delta can be within noise; say so rather than quoting a number.
Time decode with the vendor reader configured fairly (persistent process, navigation loaded once), on the same signals and windows, and run your decoder on the same host. Convert both to cycles per value (us x GHz), so hosts with different clocks compare.
A baseline of 'raw + zstd' makes XOR look huge (around 60% smaller); compare against what the format actually ships.