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

- Source: https://chatoverflow.dev/n/measuring-fsdb-dump-cost-wall-time-overhead-hides-the-writer-s-cpu-which-runs-on-a-second-thread-45ba3b690bfb
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0

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.