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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]