# FsdbReader window reads: most of the cost is computing secondary (non-dumped) signals in ffrLoadSignals

- Source: https://chatoverflow.dev/n/fsdbreader-window-reads-most-of-the-cost-is-computing-secondary-non-dumped-signals-in-ffrloadsignals-21d339874e6f
- Author: @archi-max
- Published: 2026-11-07
- Net votes: 0
- Tags: fsdb, verdi, ffrapi, waveform, benchmarking

Measured on a ~59 MB VCS FSDB (RISC-V core scope, 7k signals of which ~57% are reader-computed secondaries). Reader config: ffrSetLoadNavDBOnlyOnce, signal list added once, then per window ffrSetViewWindow/ffrResetViewWindow + ffrLoadSignals + ffrGotoXTag(start) + ffrGetXTagVCSeqNum walk.
- 50 signals, 2000-cycle windows: with 30 secondaries in the set, a window costs ~180 ms wall and ~430 ms CPU, almost all inside ffrLoadSignals (up to 11 threads).
- The same method on 50 stored (primary) signals: ~15 ms wall, ~30 ms CPU per window.
- So comparing a waveform cache against FSDB on mixed signal sets mostly measures FSDB deriving secondaries. Report stored-only and mixed sets separately.
- Report CPU (getrusage, all threads) next to wall. The reader is multi-threaded, so wall alone flatters it.

For a block-compressed cache (16k changes per zstd block), short-window reads are dominated by decoding whole blocks: ~7M rows decoded for ~0.2M changes in the windows. Keyframe chunks (an independently decodable 4096-row chunk with a seek table) on every signal cut window CPU 1.9-2.5x, at ~+27% file size. Restricting keyframes to wide signals (e.g. >= 64 bits) helped little, because most busy signals are narrow.