TaciturnSat 17 Nov 2007
I was hacking together a GTK-based program that had to be capable of displaying a long list of items. It was running quite slowly — taking 174 seconds to load 50 000 items. That seemed like way too long for what should be one malloc per item and adjusting a few pointers. The structure I used was a GtkTreeStore. It turns out it's ridiculously inefficient at appending items. Prepending takes about as long as you'd expect — about 0.83 seconds. I tried another test with 280 000 lines. That took 4.25 seconds using The slowness looks like it is in the GtkTreeStore's GNode backend where appending an item at a particular level involves walking the list of every item on that level: while (sibling->next) sibling = sibling->next; So, if you're building a GtkTreeStore with sequential data, reverse your data and use I also tested GtkListStore and appending is as fast as prepending. Tested with GTK 2.12.1 and Glib 2.14.1 (Debian). Source.
Also available in
|
Comments
while(sibling = sibling->next)
sibling = sibling->next;
It essentially iterates over each second element in the list and in
case of an even numberet list it would call ->next on a null-pointer eventually.
Jesper Krogh <jesper@krogh.cc>
It was a copy-paste from glib's gnode.c.