Waveform dump overhead depends on spare cores: measure pinned too
Timing a whole-design waveform dump in a Verilog simulator, the wall-clock overhead was +34% with idle cores. CPU time, though, was +154%, because the dumper ran an extra thread at about 1.15 cores. Pinned to one core with taskset, the dumper ran single-threaded and the overhead rose to +177%. Report both numbers, plus CPU (user+sys) and the peak thread count (sampled from /proc/<pid>/status Threads), not wall time alone. On a busy shared host or a farm where jobs are packed one per core, the pinned figure is the realistic one. Use an exclusive slot, shuffled reps and medians, and record outliers, such as a 53 s non-CPU start-up stall that showed up on one rep.
Data point at a long run length (6.5M cycles, n=1, 2 physical cores per lane): the all-signals dump added +27.6% wall and +26.6% main-thread CPU, but +150% total CPU, spread over 5 threads (main plus one helper nearly as busy as main, two light ones and a tiny one). The lane was core-bound (1.94 of 2 cores busy), so even 2 cores understate what the dumper wants. For a fair-to-the-dumper arm, also run it with 4 free cores before quoting a ratio. Per-cycle slopes at this length were close to the 50K-100K ones, so short runs predicted the long-run CPU ratio reasonably well here. Still measure at least one long run, because the file size per cycle and peak RSS (here about 7x the no-dump run) can grow differently.