Load parameter values in FST file without reading all value change blocks

[Lramseyer]

This is a bit of an obscure request, but I noticed that when I load parameter values, I have to use load_signals(). When I call this function, it looks like it's looping through all of the value change blocks.

While this is pretty fast for small waveform dumps, there's a noticeable latency for larger files. This wasn't a problem when I had users load the waveform into the viewer, but now I plan on showing parameter values inline in the netlist view (kind of like how Surfer does) that means extra latency. I noticed a discussion last year, (#20) and the proposed solution was to pre-load all parameter values at the beginning, but this adds extra latency to file loading.

Since parameters don't actually change, would it be possible to have some sort of function like SignalSource::load_initial_value() that only loads the first value of a signal?

[ekiwi]

Could you quantify the latency that you are facing? Are you talking about VCD or FST files? Do you see the same latency with the parameter pre-loading functionality in Surfer?

[Lramseyer]

I am mostly concerned with FST files, since with VCD files, all of the Value Change data has to be read when the file is opened. Users who are using larger waveform dumps are less likely to be using VCD files.

I am using Vaporview, which compiles wellen to WASM (single threaded) and I tested it out with 3 separate files. The function that calls read_body() also calls load_signals() on all of the signals that are parameters, so I have the time logged with and without the feature enabled.

OS: Mac OS Tahoe
CPU: Apple M4 Pro
RAM: 48GB

*	File 1	File 2	File 3
Size	19 GB	2 GB	2 MB
Scopes	400,682	50,180	32
Variables	804,598	101,154	191
Value Change Blocks	978	142	7
Time Table Count	807,062	802,418	28,220,938
Netlist Hierarchy Load Time	0.648s	0.115s	0.337s*
Read Body (Without Parameters)	0.002s	0.002s	0.052
Read Body (With Parameters)	5.818s	0.270s	0.421s

*Note that files smaller than 256 MB are statically loaded in, and may take longer to read the netlist hierarchy

It looks like its not a huge problem until you get to larger waveform dumps, but it looks like the number of VC blocks in an FST file has an affect on parameter load time.

[ekiwi]

Thanks for reporting these numbers. I see how for the 19 GiB file, waiting an additional 5s is unacceptable. Unfortunately, I won't have time to implement an optimized load signals function at the moment. If you would like to try, the starting point would be the fst-reader library. It might be enough to just add some extra code to not load the timetable for a VC block if none of the signals you are interested in change in that block. That way you would not have to add a special function just for constants.

Optimizing this case in wellen is going to involve quite a bit of work, regardless of who does it. For now, I would recommend trying to implement the approach that Surfer takes, which is to just load parameter values in the background. This way, you can show the user the hierarchy after less than 1s and then, after an additional 5s, parameter values will be shown. During the time it takes to load the value of parameters, you can just display a placeholder. Something like NUM_CPUS = Loading ...