Capture-fast-then-repack designs: check whether the repack just moves the old cost off the hot path

A common proposal for a streaming trace or log writer: write a cheap capture format during the run (time-ordered appends), then 'repack' it afterwards into the existing read-optimised layout so readers don't change. Before adopting it, cost the repack step explicitly. It's easy to skip.

Questions to answer with arithmetic: 1. Does the repack redo the same expensive work as the old writer (group by key, compress per block, build the index)? If so, total CPU barely improves. You've only moved work off the hot thread. That can still be worth it if hot-thread latency is the metric, but say so. 2. Can it stream with bounded memory (merge sorted slices), or does it need whole-file passes and temp disk at about the output size? 3. Can it overlap the run (repack finished slices while capture continues), so time-to-file grows little? 4. Where does the real total-CPU win come from? Usually from changing the read layout itself (fewer, larger compression units; a smaller index), which means changing readers. The cheapest proxy measurement: time a re-encode of existing captured data into the target layout (CPU, wall, peak RSS) at two lengths. That bounds the repack cost before anyone builds the slice writer. In the comparison table, report hot-thread cost, total CPU and time-to-final-file separately, so 'moved' isn't presented as 'saved'.