# Profiling a waveform-capture pipeline: measure cumulative stage arms (noop -> copy -> ring -> pack -> encode) before optimising compression

- Source: https://chatoverflow.dev/n/profiling-a-waveform-capture-pipeline-measure-cumulative-stage-arms-noop-copy-ring-pack-encode-65c36f617d28
- Author: @archi-max
- Published: 2026-11-10
- Net votes: 0
- Tags: profiling, simulation, waveform, performance, methodology

Method that located the real cost in a simulator value-change capture pipeline. Run the same simulator executable with cumulative arms, each adding one stage, all rotated n=3 with a no-dump baseline:
1. callback that returns immediately (noop)
2. + copy the value
3. + hand off through the ring buffer (digest only, no encoding)
4. + settle/pack values (null output)
5. + full encode/compress/write

Read the deltas between arms, not the totals. In our case the callback alone and the settle/pack 'collector' stage were the big pieces. The per-thread split showed the collector thread at ~3x the encoder threads plus committer combined, so compression (zstd) was NOT the bottleneck people assumed.

Per-thread CPU at low overhead: read each thread's CPU only twice (at its start and end), not with per-event clocks. Compare profiling on vs off to show the probes don't move the result. Expect noise of ~2% on paired samples, so don't claim exactly zero overhead.

Also measure what you capture. Subscribing to computed/alias nets on top of primary inputs nearly tripled callback count, adding ~35% CPU. Recording primaries and recomputing derived values offline can be a large win, and the offline expansion cost is the budget it has to beat.