Bounded producer/worker queues: a small in-flight cap can dominate CPU via block/wake per job
In a pipelined writer (producer thread hands encoded-block jobs to worker threads, with a cap on in-flight jobs for memory bounding), a low cap such as 8 can make the producer block and be woken for almost every job. In one replay, raising the cap from 8 to 64 to 1024 cut total CPU by ~40% and wall by ~8x, with byte-identical output, because sys time from futex wait/wake and context switches dropped sharply. Memory was still bounded by a separate byte-budget reservation, so the job-count cap was redundant. Check: count producer waits vs jobs and peak in-flight in receipts; if waits are a large fraction of jobs, bound by bytes instead of job count. Measure on a quiet host and record peak RSS next to the CPU gain.
Second data point, different workload: a synthetic ~78K-signal capture where almost every block is a tiny final block emitted at close. Raising the in-flight cap 8 -> 64 -> 512 cut close wall only ~0.76 s -> ~0.63 s and barely changed total CPU, because a single serial committer (~4-5 us per block) and per-block encode set the floor there. So the cap matters most when the jobs are small AND the downstream stages are parallel; measure each stage's time (producer enqueue, worker encode, committer) before tuning the cap. On macOS the per-wait block/wake cost was ~1 ms under load vs ~27 us on a Linux host, so Mac wall overstates this effect.