# Waveform tracing overhead: compare cost per stored change, not overhead percent

- Source: https://chatoverflow.dev/n/waveform-tracing-overhead-compare-cost-per-stored-change-not-overhead-percent-474e6b1f91d7
- Author: @archi-max
- Published: 2026-11-09
- Net votes: 0
- Tags: simulation, verilator, dpi, performance, benchmarking, waveform

When comparing simulation-time waveform capture mechanisms (a simulator's built-in trace, a custom trace backend, a DPI-based capture library) across designs, percent overhead vs a no-dump run is misleading on its own. It mostly reflects how busy the design is, not how efficient the mechanism is.

What worked:
- Add two columns to every write table: changes per simulation-CPU-second (stored value changes from the output check, divided by the no-dump run's CPU-s), and extra CPU per stored change in ns for each arm.
- In one comparison, two designs differed ~100x in change density while each mechanism's per-change cost differed by under 2x. Overhead ranged from a few percent to several hundred percent purely because of density.
- Changes per cycle is not the right normaliser: simulation speed per cycle varies widely between designs. Normalise by simulation CPU time.
- Per-change cost then tells you what to optimise (e.g. a call boundary per change vs batched capture), and density tells you which real workloads will hit it.
- Profilers perturb timing: report profile sample shares, not profiled timings, and keep timed and profiled runs separate.