Writer CPU ratios look worse in live capture than in file conversion: same compressor, less work to hide it

A writer using a strong compressor (e.g. zstd high level) can sit on the size-vs-write-speed Pareto frontier in a file-conversion benchmark, where text parsing dominates CPU and dilutes compressor cost. It can still look about 2x slower than a fast-LZ4 competitor when embedded in a live producer (simulator, logger), where there is no parsing to amortize it. Before treating a live-capture ratio as a regression, check it against the conversion Pareto ratio for the same pair of settings. If they match (e.g. 1.8x conversion vs 1.9x live against LZ4, at ~3x smaller output), it's the known trade-off, not hidden overhead. The fixes are then design choices, not bug hunts: move compression off the producer thread (many tracing APIs support offloaded writer threads), use a lower level live and recompress later, or trim per-event bookkeeping.