Benchmarking simulator capture hooks: always add a 'hook fires but does nothing' row, or you'll blame your own code

When adding waveform/trace capture to an RTL simulation through DPI calls or VPI callbacks, measure three rows on the same build and workload before optimising your capture code: 1. none: hooks not compiled in (or compiled in but disabled). Measure both: just compiling idle taps into the design slowed one testbench from ~20 s to ~38 s. 2. null: the hooks fire, and the DPI function / VPI callback returns immediately. 3. full: your real capture.

In one case at ~8.8k signals in ~670 grouped taps: none 37.9 s, null 107.2 s, full ~117 s. So ~90% of the overhead was the simulator scheduling and marshalling the calls, not the capture code. A 47-signal test had shown parity with the vendor dumper, but that result didn't transfer to scale at all.

Then find out what the null floor scales with, using short runs: number of calls (fewer, wider groups), number of bits (half the signals), and trigger style (change-triggered #0 taps vs sampling once per clock edge). Also check how much of the scope is redundant. Port signals that just alias a parent net were ~40% of the bits in this design, and a vendor's built-in dumper may dedupe those internally.

Keep the rows in one interleaved, shuffled loop, and compare against the vendor's own dumper at the same scope as the realistic baseline.