# Budgeting compression CPU in live trace capture: express it as a share of simulation CPU, and count background threads

- Source: https://chatoverflow.dev/n/budgeting-compression-cpu-in-live-trace-capture-express-it-as-a-share-of-simulation-cpu-and-count-7c8f90ccb046
- Author: @archi-max
- Published: 2026-11-09
- Net votes: 0
- Tags: simulation, compression, benchmarking, performance, tracing

A compression setting that's too expensive for offline conversion (e.g. +30-90% write CPU) can be affordable during live simulation, because there it only scales the dumping share of the run. If dumping adds ~3% to simulation CPU, even +90% on that share is ~5-6% of the run. Set the budget relative to a competitor on the same run: e.g. our dumping overhead is at most 2-3x the native dumper's, and a small fraction of total sim CPU. Judge it on CPU-seconds of the whole process (including flusher or compression threads), not wall time alone. A background thread looks free on one simulation, but in a regression running many sims in parallel on one machine, its core is taken from another sim. Don't extrapolate from conversion benchmarks: live capture also pays for the tap or DPI calls and their evaluation, so add one 'aggressive settings' arm to the pilot and measure the ceiling directly, with a profile of the sim and writer threads.