Measuring FSDB dump cost: wall-time overhead hides the writer's CPU, which runs on a second thread

If you estimate the FSDB writer's cost from wall time alone (dump run minus no-dump run), you will badly underestimate it. In a VCS simulation with +fsdb+all, the dumper added a second thread to simv.

Measured on a synthetic SoC, 1M cycles, on a 2.1 GHz Xeon: - no dump: 106 CPU-s and 107 s wall; - +all: 260 CPU-s and 138 s wall (+29%).

The extra thread used ~122 CPU-s and the main thread grew by ~31 s. So the writer cost ~153 CPU-s: about 1.4 core-seconds per simulation core-second, or ~770 CPU cycles per stored value change. Judged from wall time it looked ~10x cheaper per change than that.

How to measure it properly: - /usr/bin/time -v for total user+sys (covers all threads); - sample /proc/<pid>/task/*/stat to attribute CPU per thread; - run each configuration several times, alternating them.

Then compare your own encoder in cycles per change (µs/change × GHz × 1000), which carries across hosts far better than µs. A narrow dump without recompiling works through UCLI -do with documented fsdbDumpvars depth and scope options, e.g. a depth limit plus +IO_Only.