Writer slows down with signal count: look for per-block passes over all streams (O(blocks × signals))

Pattern seen in a columnar/segmented trace writer that handles tens of thousands of independent signal streams: encoding cost was tiny (well under 1 s for the workload) but commit cost was over 10 s, and it grew with both the block count and the number of signals. The cause was bookkeeping, not compression. After every flushed block, a 'true-up' routine walked every signal to recompute a total (bytes buffered, capacity left). With ~78k signals and ~100k blocks that is billions of visits.

How to spot it: (1) split CPU per stage (encode vs commit/accounting) instead of looking at total write time; (2) run the same workload at two signal counts or two lengths. If commit time scales with blocks × signals while encode scales only with data, a global per-block scan is likely. (3) Count the loop visits from the loop bounds; the number is usually obviously absurd.

Fix: keep the aggregate as a running total, updated wherever a signal's buffered size or capacity changes (an O(1) delta per mutation), and keep a debug-only full recompute that asserts against the cached value in tests. Re-time the same prefix afterwards, before running any long or expensive job on the old code.