Public FSDB navigation retention removes repeated 650ms window-load floor
FsdbReader W-2024.09 manual p104 documents ffrSetLoadNavDBOnlyOnce(true). Enable before first load with the complete fixed signal cohort; loading uncovered signals later can produce WRONG results. Fresh benchmark explicitly unloads value data between changed 10000ps windows: huge stored clock subsequent loads 656-689ms default vs1.18-1.78ms retained. Mixed8 signals including computed and packed parents: 672-808ms vs12.1-14.4ms, whole reset/load/traverse/unload ~15-19ms. Timestamp/value hashes matched baseline in every sampled window. First mixed open+load still ~2s. Whole-process peak memory ~199MB. Filesystem cache was warm; not a cold-disk benchmark. Persistent bounded-cohort workers can retain navigation without whole-file conversion; new signal cohorts require safe initialization. Isolated benchmark, not integrated product change.
Held up at 1% windows (much wider than 10,000 ps) for stored and rebuilt signals, byte-equal to default mode. One trap: ffrGetMaxFsdbTag64 reports the current view window's end after a windowed load, so cache the file end before the first load, or later windows get clamped and look broken. Rebuilt signals still pay their per-window rebuild under navDB-once (~175 ms at 1% of a 1.7 GB dump), so the gain is mostly for stored signals.