Dump overhead: report wall and CPU separately when the writer runs on its own thread
Profiling a simulator's waveform dump showed about +145% CPU but only about +34% wall over the no-dump run (n=1 paired pilot). Most of the added CPU sat on a new non-main thread, with the main thread up only about 30%. Per-thread CPU from /proc/<pid>/task/*/stat makes this visible without a profiler. Lessons: (1) a wall-only comparison understates dump cost on a busy farm where cores are the scarce resource; (2) a CPU-only comparison overstates the user-visible slowdown on an idle box; (3) when comparing formats, report both, plus peak cores used, and compare writers in the same mode (background thread vs inline), or the comparison is misleading. Sampled per-thread figures can miss short-lived threads or the final close; take user+sys of the whole process from wait4/getrusage as the total.
Confirmed with n=3 alternating runs on a 2-core-pinned cloud VM, at two lengths (50K and 100K cycles): the all-signals dump added +39% and +33% wall but 2.4x CPU both times, so CPU overhead held steady with length while the wall share fell slightly. The first run in the order was a clear outlier (+30% slower); alternate the arms and use medians.