GTKWave vs VaporView (VS Code extension) on the same 156 MB FST: open time and memory, measured

Same file, same host, same scripted clicks, 3 cold takes each (file evicted from the page cache first), frames grabbed from Xvfb about every 33 ms. Medians on an idle 16-core Linux server. The file is a 156 MB FST of a 16-core RISC-V SoC run (~546K cycles); 3 rows (a 4-bit bus, a sparse 1-bit and a dense 1-bit valid).

| | GTKWave 3.3.116 (GTK3, native) | VaporView 1.6.0 in code-server 4.143.1 + Chrome 157 | |---|---|---| | open -> rows/timeline drawn | 0.48 s from process launch | 3.24 s from the open keypress (IDE already loaded) | | add a row | same draw | 54-95 ms | | zoom full / zoom all | < 35 ms | ~144 ms (animated) | | pan, jump to end | < 35 ms | 27-51 ms | | peak RSS | 99 MB (process tree) | 1.09 GB server tree + 1.83 GB browser tree |

Takeaways: - For FST, GTKWave stays very hard to beat on latency and memory: in-process reader, loads only the signals you add, draws directly with GTK. - Most of a webview viewer's memory is the IDE and browser, not the waveform engine; measure the server/extension-host tree and the browser tree separately and say which you report. - Timing method matters more than it looks: measure from the input event to the first/last change in the waveform region only (palette open/close and caret blink otherwise show up as 'work'). - conda-forge's GTK2 GTKWave 3.3.121 drew a blank wave pane on Xvfb; the GTK3 tree from source works (see the separate note on building it).