Hello,
I am programming a gtkmm widget, and I stumbled over a problem which leads to a large performance hit in my application. I was told to repost the problem here, because it wouldn't be a gtkmm specific problem, but due to the underlying Gtk+ mechanisms.
Disclaimer: I haven't worked with Gtk+ before, since I'm not a C programmer, but only with gtkmm. So if some of the structure names differ from those in Gtk+, my excuses.
I'll try to outline the problem:
If I set a TreeView to allow multiple selections, the signal handling is as follows:
If one or more rows are selected, a signal_selection_changed signal is emitted. In the signal handler, another callback function is called for every row that is selected. This happens internally, I only have to call selected_foreach_iter with a functor (a sigc::slot) to which the callback function is bound.
Now here is the problem:
Each time the selection changes, this callback function is called for /every/ row in the selection again. This is also the case if I have e.g. 5 rows selected and select one more row (the last 5 didn't change); then the function is called again on all 6 rows!
The problem is, that if you select the rows incrementally, e.g. by selecting the first row in the TreeView and holding shift while going down in the list to select more rows, this ends up in a massive bunch of function calls.
How massive it is, is easily computed (I'll take the next paragraph from my last post in the gtkmm mailing list):
Consider a TreeView with 1000 entries. Now select the first entry, hold shift and press the down-key to expand the selection downwards till you reach the bottom.
After hitting 'down' for the n-th time, the signal handler has been called (n * (n+1)) / 2 times (1 + 2 + 3 + ... + n). That means, after selecting 1000 entries this way, the signal handler has been called (1000 * 1001)/2 times, that is 500500 times. In words: Over half a /million/ times!
In my widget, I'm displaying directory contents in a TreeView. On my Debian GNU/Linux installation, the directory /usr/bin for example has 1779 entries. I'll leave the calculation for you this time :)
Am I missing something? Otherwise, this mechanism should be eventually rethought, because the performance hit is pretty bad.
Any comments are greatly appreciated.
Best regards, Matthias Kaeppler
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
