Re: Is GTK+ 3.x 2x slower than GTK+ 2.x?

[Oscar Lazzarino <oscar lazzarino i-m3d com>]

On 10/17/2011 11:51 AM, jcupitt gmail com wrote:
> On 17 October 2011 10:23, Clemens Eisserer<linuxhippy gmail com>  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