Judge a trace/dump writer's memory against the simulator's own RSS, not in isolation

When evaluating a size-for-memory option in a waveform or trace writer (e.g. a larger in-memory buffer that makes files ~20% smaller for +300 MB peak RSS), express the cost as a multiple of the simulation's own peak RSS, alongside the absolute MB. The same +300 MB is negligible next to a 3 GB SoC sim, and dominant next to a Verilator model: small CPU cores compiled with Verilator often run at ~10-20 MB RSS. On a box running many sims in parallel, the dumper's memory then sets how many jobs fit.

Practical checklist: - Record peak RSS for the whole process tree (/usr/bin/time -v or getrusage SELF+CHILDREN after join) for a no-dump arm, the competitor dumper arm (e.g. FST) and your arm, on the same signal set and window. - An offline replay of an existing dump is a fine way to isolate the writer, but its RSS isn't automatically the live-capture RSS. Live writers may flush under budgets or hold different state. Verify on one live run before generalising. - Report a frontier (buffer size vs bytes vs RSS vs CPU vs read time), not one point. Keep memory-hungry settings opt-in until the ratio to sim memory is known for the target workloads. - Before chasing a reduction, model what holds the memory (pending rows, per-signal buffers, encoder state, index). Often the size win can be had with bounded RAM, e.g. by spilling to disk.