Re: Programmer's criticism of GTK2

[Carlos Pereira <carlos pehoe civil ist utl pt>]

> > -Simplicity. Add a row to the GtkCList (with all data) and to the
> > list_store. Compare code length :-)

> I'd like to think that GtkTreeView is much more flexible.  You can do a
> lot more with it.  Part of the price of this flexibility is complexity.
> I've contemplated making a CList-like list wrapper that people can use,
> and am still undecided if it's a good idea or not.

This is from my experience with Gtk1.2:

I ask Expat, the non-validating XML parser,
to read a XML file with 10,000 objects, then
I parse myself everything checking for a ton
of possible errors, then I construct a queue
of dlists and a stack of slists, create the
memory for all the objects and in the end,
if everything went fine, I have to link all
these objects, clean the whole thing, and ask
my mesa-based graphic engine to draw everything.

In this computer (double PII400 with 0.5 Gb RAM), 
the whole thing takes about 0.5 sec (this is not
even optimised yet, because I am still using malloc
to create one object each time).
Then I open a dialog which has a GtkCTree of the
10,000 objects, and it takes between 3 and 4 sec
before the window comes up. 
After the tree is created, navigating 
through the nodes is fast. 

If I apply a real torture test, say, about 79,000
objects, it takes about 3.5-4 sec from reading the XML file
to finish drawing. I don't know how long it would take to
create the GtkCTree because I always give up after
30 sec or more waiting for it.

Clearly the problem is the function that builds the
nodes:

node = gtk_ctree_insert_node (ctree, node,
NULL, &name, 0, NULL, NULL, NULL, NULL, FALSE, FALSE);

This call has 11 parameters, which makes it very flexible
but also very slow. In my case, almost all this functionality
is definitely not used: most parameters are NULL, FALSE or 0.

Definitely flexibility is very important, no doubt
about that, but in many cases raw performance is
really critical, particularly in engineering and
scientific applications.

A possible solution would be to have
more than one function for the critical 
operations, as inserting nodes; tuned
for performance or for flexibility.

Another solution would be users to
copy the code of the flexible function 
to its own code and then simplify it 
according to its own needs. Among other 
obvious disadvantages, I believe this 
cannot be done in non-[L]GPL software.

Carlos