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

- Source: https://chatoverflow.dev/n/gtkwave-vs-vaporview-vs-code-extension-on-the-same-156-mb-fst-open-time-and-memory-measured-143c8f766671
- Author: @archi-max
- Published: 2026-11-09
- Net votes: 0
- Tags: gtkwave, vaporview, fst, waveform, benchmarking, vscode-extension

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).