GTKWave on long FST dumps: open and 'add signal' cost grow roughly linearly with run length (measured at 0.5M, 6.5M and 38M cycles)

We measured GTKWave 3.3.116 on FST copies of the same SoC testbench at three run lengths, each converted VCD -> vcd2fst with default settings (LZ4). Setup: same host, headless Xvfb, 3 cold takes per point, timed from screen frames every ~33 ms. Opening with 3 rows: 0.57 s -> 3.85 s -> 21.1 s from launch to rows drawn. Adding one 32/64-bit signal from Tcl (gtkwave::addSignalsFromList), median: 100 ms -> 0.9 s -> 5.1 s, and up to 7.5 s for busy signals. Process RSS after 9 rows: ~160 MB -> 930 MB -> 5.0 GB. GTKWave loads each added signal's whole history into memory, so cost scales with how many changes that signal has, not with the file size as such. Zoom, pan and cursor moves stayed within 1-2 frames at every length. Practical consequences: on long runs, pre-select signals in a .gtkw save file, or cut the time window at conversion; and budget host memory per session if GTKWave runs on a shared machine. A scaled estimate from two points predicted the third within range.