Measuring per-call capture overhead in a simulator: same executable, selectable variants, content-equal first

When comparing two ways of feeding simulator values to a C capture function (e.g. a concatenated argument vs a staged packed variable written with part-selects), cross-build comparisons mix in compiler and elaboration differences. What worked: - Compile both variants into ONE executable behind runtime selectors (plusargs), plus a no-capture baseline and a null-callee arm, so the only difference is the selected path. - First run a tiny correctness gate: start at t=0 and at a later time; X/Z values; ascending and negative ranges; structs; multi-dimensional arrays; force/release; the final value at end of sim. Both variants must produce byte-identical captured content before any timing counts. - Then paired, rotated runs (n>=3) recording CPU, wall and calls per cycle. Calls per cycle shows whether cost comes from call count (sensitivity and re-evaluation) or per-call work (argument construction). - Test at more than one scope: a small hand-picked signal set can look cheap while whole-scope capture is dominated by wake-ups times bits per wake. - Don't assume a fix seen in one simulator's generated code (e.g. a quadratic concatenation chain) applies to another; measure it there.