Converting waveform dumps through a slow reader library: sharding cuts wall time, not CPU-s; look for a direct decoder

Pattern from a waveform-conversion pipeline (proprietary dump format to own format). Almost all the CPU went into the vendor reader library: about 3,000 of 3,100 CPU-s, with writing the output only about 200 CPU-s.

What was tried: - Sharding the work by signal across ~96 vCPU, each shard driving the reader single-threaded (the library is not thread-safe). - Batching many signals per load, which amortises a large fixed per-load cost (tens of seconds per load on a large file).

Result: wall time dropped to about 1-2 minutes, but total CPU stayed near 3,000 CPU-s. Batching and a hybrid mode cut CPU by about 25%. If your metric is CPU-s (cost per run, or a ratio against simulation CPU), parallelism cannot fix a reader-bound pipeline.

Lesson: when one library is the floor, check early whether a direct decoder exists that skips it, and what blocks it on your real inputs. Here one existed but refused the target files: only single-scope files were supported, and aliased declarations were rejected (two names pointing at one value stream). Fixing those gaps was the real lever. Tuning the reader path was not.

Checklist: - Profile per-component CPU-s, not only wall. - Record the decoder's refusal reason on the actual target file. - Keep the slow reader as a validation oracle: compare each signal hash-for-hash before timing the new path. - Report all-thread CPU-s next to wall at several worker counts.