[Gtkwave-users] Performance problem when signals are displayed in groups

[Pawel J. <paw...@gm...>]

Hi GtkWave Developers,

Displaying signals in groups is very useful feature in gtkwave,
allowing to deal with big designs with many signals.
Unfortunately, there is a very strong performance degradation if
displayed signals are grouped and (several) groups are closed.

I have prepared a simple example to demonstrate the problem.
Arrached groups.zip contains:
“t100_50.fst” – waveform file with 100 signals with 50 events on every signal
“grp_open.gtkw” – config file displaying the above signals in groups
“grp_close.gtkw” – config file displaying the above signals in closed groups

When gtkwave is started with the first config file:
gtkwave t100_50.fst grp_open.gtkw
gtkwave starts quickly and signal browsing is very fast.

But, when the same signals are in “closed” groups:
gtkwave t100_50.fst grp_close.gtkw
the program start-up takes much longer, and simple signal browsing is
extremely slow.

The same effect can be achieved starting gtkwave with “grp_open.gtkw”
config file and closing the groups (one by one) with Edit / “Toggle
Group Open|Close”.

Running with profiling, I noticed that the problem is related to the
following functions in analyzer.c:

UpdateTraceSelection() calls GivePrevTraceSkipUpdate(with skip = 1)
GivePrevTraceSkipUpdate(skip = 1) calls GivePrevTrace()
GivePrevTrace() calls GivePrevTraceSkipUpdate(with skip = 0)
GivePrevTraceSkipUpdate(skip = 0) calls UpdateTraceSelection()
UpdateTraceSelection() calls GivePrevTraceSkipUpdate(with skip = 1)
And so on …

The recursion eventually complete, but the number of calls can be
quite impressive.
Example output fragment from GNU profiler (start-up only):
time   seconds   seconds    calls   s/call   s/call  name
 54.02      7.32     7.32 1209529652     0.00     0.00  GivePrevTraceSkipUpdate
 37.34     12.38     5.06 302382982     0.00     0.00  UpdateTraceSelection
  7.97     13.46     1.08 302382733     0.00     0.00  GivePrevTrace

Function UpdateTraceSelection() is called on view change (for example:
signal up/down scroll) making the browsing painfully slow.

Maybe you could take a look if it can be corrected?
(I would suggest to rewrite the code to avoid recursion back to
“UpdateTraceSelection()”.)

Thank you for a great tool :)

Thanks,
Pawel