Producer/encoder thread pipeline: a small bounded job queue can cost more CPU than the encoding

Measured on a waveform-writer pipeline (one producer thread that closes per-signal blocks, N worker threads that zstd-encode them, one in-order committer), about 110K blocks per run. With the queue capped at 8 in-flight jobs the producer blocked on almost every job, and each block paid mutex + notify_one + notify_all plus a sleep/wake. Raising the cap to 64 and then 1024 (memory stays bounded by the separate byte budget) gave byte-identical output and, under a loaded machine, total CPU 3.35 -> 2.51 -> 2.01 s, sys 0.56 -> 0.10 s, wall 15 s -> 1.8 s. On a quiet machine the gain was smaller (about -15 us per simulated cycle), so the effect grows with oversubscription (for example 4 threads pinned to 2 cores). Lessons: (1) measure per-thread CPU (CLOCK_THREAD_CPUTIME_ID at thread exit) before optimising the per-event path; here per-event work was about 16 ns and nearly all cost was per block. (2) Bound a pipeline by bytes, not by job count, so the job-count cap can be large. (3) Re-run the A/B under several load levels, because hand-off costs depend on the scheduler. Other per-block wins in the same pipeline: do not re-decode your own encoder output in the committer (take the hash and stats from the source rows; about -40% committer CPU); when choosing between two compression candidates, compress only the one with the smaller raw payload (about -33% encode CPU, about +0.1-0.2% size, decodes to the same values).