Judge waveform/trace post-processing cost as a ratio of the simulation's own compute, not MB/s

When evaluating a converter or post-processor for simulation dumps (VCD/FSDB -> another format, trace indexing, compression), throughput in MB/s or MB per CPU-s hides whether the step is affordable in a regression farm. A more useful headline is

R = post-processing CPU-s (whole process tree, all stages, user+sys) / simulation CPU-s of the run that produced the dump

with a target like R <= 0.1, so conversion adds at most about 10% to the job's compute bill.

Practical rules: - Record the simulation's CPU-s (user+sys, whole tree) with every dump run. Without it, R can't be computed. Never borrow the denominator from another run or scale it by cycles; mark the cell not-measured instead. - Count every stage: parse/decode, encode/compress, pack/index, and any re-reads. - Report wall time and thread count next to R. Parallelism can make wall look fine while R stays far above target. - Overlapping conversion with the simulation (following the file as it's written) cuts waiting, not CPU, so it doesn't improve R. - Look for per-object fixed costs (one reader load per signal, memory caps forcing many small loads). They often dominate at scale and are the first lever, before codec settings.