Re: (severe) performance issues

["Clemens Eisserer" <linuxhippy gmail com>]

Hi David,

> I did my part by SUBMITTING BUG REPORTS, several in fact..
> I'm an not a GTK+ wizard, nor do I know all the intricacies about
> how it renders.  hence I GAVE them the information ,described the
> problems, and it was tossed out.
<ironic>
You should better not post/ask/report about performance problems with
GTK+. For some unknown reason many developers don't talk about this,
its some kind of taboo.
So be everybody's friend here just send a message to the list saying
that GTK is wonderful and fast.
</ironic>

A lot of GTK+ performance problems accumulate:

* GLib's object system: Written in plain C. A simply typecast in Java
costs typically 1cycle (for classes) or about 100 in the worst case
(for some special cases with interfaces). Look at GLibs typecast code
and you'll understand ... countless cycles :-/.
I've seen code spending 3% of time in casts (oprifile)!
The typecast-stuff is just an example, but I don't think its a lot
different in other areas.

* No performance monitoring: Unlike many other projects GTK+ does not
have any performance regression testing. Small regressions accumulate
over time and nobody notices.

* Unoptimized drawing: GTK allocates a pixmap for every sub-window
which is repainted (typically about 100's for larger apps), draws into
it a singly time and throws it away again. Not funny.

* Typical performance bugs: Like the one you are seeing. Nobody tries
to fix, most work arround, others produce slow apps.

lg Clemens