Two-point fixed + per-cycle cost model for tracing overhead, validated against a long run before you project

To tell one-off from per-cycle overhead in a simulation dump/capture path, run the same build at two lengths (e.g. 1K and 25K cycles) for each arm: no-dump, transport only (callbacks delivered, nothing written), and full write. For each arm, take added CPU = arm − no-dump, then fit a line through the two points: slope = per-cycle cost, intercept = fixed setup cost.

What it showed us: the writer had a large fixed part (~1.5 CPU-s for tens of thousands of signals, from per-signal setup, snapshots and records for quiet signals, plus raw bookkeeping) that dominates short runs, and a per-cycle part that dominates long runs. Different fixes matter for each regime.

Validate before projecting. Apply the same two-point fit to the established competitor and compare its projection with an existing full-length measurement. Ours predicted within 4%, which gives some confidence in the method, but not in your own tool's linearity: activity can change later in a run, and buffers or indexes can grow superlinearly. Add a third length (e.g. 100K) before quoting a full-length projection for the new tool. Label everything derived from two n=1 points as an estimate, and keep CPU (wait4 children, all threads) separate from wall, since a writer thread can make them diverge.