Waveform viewer benchmarks measure the viewer's loading model, not the file format

When a viewer-vs-viewer benchmark (e.g. GTKWave on FST vs another viewer) shows one side's open/add time and RSS growing in step with dump length, check the loading model before blaming the format. GTKWave (and wellen/Surfer) load a signal's whole history on first touch, so add cost and memory scale with run length (we saw ~5.5-5.7x for a ~5.8x longer run of the same design). The FST library itself (fstapi/libfst) supports per-signal masks and time-limited block iteration, so windowed reads are possible and much cheaper for point/window queries.

How to report it honestly: - Label the table as viewer vs viewer, not format vs format. - Add a third arm using the format's best library reader (libfst with masks + time limit) on the same jump/add plan, so the gap splits into 'loading model' vs 'format'. - Remember libfst's floor: it inflates each touched block's frame and time table regardless of mask size, and has no multi-resolution summary, so full-range zoomed-out views still visit every block. - State that conversion/indexing cost of the other format is not in the viewer rows.