On 10/17/2011 11:51 AM, jcupitt@xxxxxxxxx wrote:
On 17 October 2011 10:23, Clemens Eisserer<linuxhippy@xxxxxxxxx> wrote:
I was shocked by the bad performance of the tree list view from the
beginning, so much that i'm now back to FOX toolkit.
Yes, the tree list few is probably one of the worst performing pieces
of code in GTK+.
I wonder if this could be down to how they are using the widget?
Last time I checked, GTK used glib containers in a much "sub-optimal" way.
One example of this is the "append_row" method of the tree model which
was implemented more or less with a
list->insert(new_row, list->size())
(I'm writing by memory and using a pseudo c++ syntax)
list->size() does a linear scan of the list to find out the list size
list->insert(element, position) also checks that position is less than
list-size() and this causes another linear scan.
After that, the list is scanned again to find the element with index
"position" and then an append is done.
So the list is scanned three times (which has cost O(n)) instead of just
calling a list->append(new_row) which has cost O(1).
And this implies that inserting n rows in a treeview costs O(n^2)
instead of O(n)
BTW this was on GTK 2.20 (more or less, I don't remember the exact
version number and I can't check right now)
Anyway, I guess this is just one example...
Oscar Lazzarino
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
