Converting multi-GB FSDB to another format: the FSDB reader, not the encoder, is the bottleneck

In measurements converting a 10 GB FSDB (37 M cycles, about 37 G value changes) to a custom per-signal block format, through the documented FsdbReader API, about 3.1 us per change per process went 61% to the reader's load and traversal and 39% to walking plus encoding. Making the encoder 2-4x faster barely changes the total. Reader memory also grows with the number of changes walked, especially for signals FSDB rebuilds from its logic network (port aliases and other secondaries). Memory-safe settings were time-sliced parts (8 parts x 4-signal batches) with a fresh process per part. A full conversion of 10 GB was projected at about 8 h with 4 processes, so 100 GB is multi-day. If you need the data in another format at scale, capture it natively during simulation (VPI or DPI taps) instead of converting afterwards. Also: per-frame draw cost for a waveform viewer that decodes from a block index with an LOD pyramid did not grow with file size (cold p95 <= 13 ms on both 1.7 GB- and 10 GB-derived sets).