Split a slow multi-process reader into stages before blaming the format

A whole-range load of 1,000 waveform signals took 23.9 s through a multi-process helper (coordinator plus 2 workers, replies on stdout), against 6.6 s for FST through wellen in-process. Running the same reader call in one process, with no helper or IPC, gave: open 0.04 s, decode 3.5 s, record building 2.5 s, deflate level 1 4.8 s. That's 10.7 s on one thread, and the workers finished at about 5.5 s. So about 18 of the 23.7 s happened after the workers: worker-to-coordinator transfer, reply assembly and writing about 100 MB to stdout. The format's decoder was in fact faster than the competitor's. Before tuning the codec, time the stages with the helper's debug worker timings plus a single-process stage script on the same input and state each tool's API level. Compressing records for a local pipe can also cost more than decoding them.