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

Re: gEDA-user: PCB GTK version...

Bill Wilson wrote: 
On Wed, 27 Jul 2005 15:41:58 +0200
Jakub Piotr C__apa <jpc@xxxxxxxxxxxxx> wrote:


Ales Hvezda wrote:

[snip]

Interesting thread, but nobody answered my first question:

What specifically is it about gtk+ 2.[4|6] that is so much slower than
say gtk+ 1.x?

That's a good question (bot wrong list probably)... :) 


I think he's asking for slower specifics wrt gschem and the gtk pcb
and not in general.


I haven't notice critical amounts of slowdown in gschem
or gtkPCB on my P2-400/256M.  Certainly pango and friends do impact text
rendering performance and I have noticed longer startup times because
of the larger number of dependencies

Blender also has many dependencies and starts almost instantly. 


On Ales' P2-400?  Blender takes several seconds to start on my k6-2 450.

I've a test program that shows Gtk pango text draws using gdk_draw_layout() can
be 20-40 times slower than xlib text draws using gdk_draw_string(), but pango
text is used in Gtk PCB only for pinout numbers and I'm not sure if it is
used on gschem schematics.  The pcb and gschem drawing areas use
gdk draw functions which are mostly short simple single function wrappers around
the xlib equivalent calls so raw drawing speed should be good.

On my k6-2 450 I see a slight slowdown of Gtk PCB compared to Xaw but
the Gtk PCB is still quite usable.  The menus appear almost instantly and
scrolling of a large layout is only slightly slower than Xaw PCB.  The Xaw
scrolling is also noticeably slower than on my Athlon 2000 machine, go figure!
At startup the Gtk PCB window appears in about 1.5 seconds and
it takes another second for the drawn layout to appear.  The Xaw PCB window
takes about 1.25 seconds to appear and the layout is drawn in slightly less than
another second.  I could spend more time and get some accurate timings, but
the slowdown is not, as Ales put it, "critical".

Just to support Ales' request, we need specific examples of where gschem or
Gtk PCB (compared to the Xaw version) gets to be objectionably slow and
on what hardware.  Based on the two examples (p2-400 and k6-2 450) so far
in this thread I would think we are talking at least sub 400 MHz machines and
I'm noticing the Xaw PCB version to start slowing down at this level also.

While Gtk can be slow for apps that heavily use Pango or large treeviews,
it really depends on the app and general Gtk complaints don't really help
with respect to any possible real issues with Gtk PCB or gschem.

And we still don't know the original posters hardware or what his
specific complaint was, and yet it sure lit some fires :)



There are a lot of things which could be going on here.

1) what hardware architecture and what compiler. Why? Newer gcc's do _much_ better on platforms like alpha and sparc than older gcc's. Not sure about i386 platforms. Also, gcc has various flags to optimize for a particular flavor of a processor. For example, on my alpha I use "-mcpu=21164a" and on my sparc I use "-mcpu=v9".

2) how were all the various libs compiled? If you turned off optimization on all of those (no -O2 or whatever) you'll take a hit. Also, doesn't gtk have some sort of debug code which can be turned on which hits your runtime performance? I seem to vaguely recall something about this. Can't recall if it is an environment variable at runtime or a configure flag/compiler flag at compile time.

3) how good is the dynamic linker on your operating system. As an example, on NetBSD-1.6 on DEC alpha systems, the runtime linker was very slow. Apps which used gtk2 with all of the various shared libs were very slow. Painfully slow. Someone went in with a big hammer and made some major improvements and as a result gtk2 apps on NetBSD-2.0 on the same DEC alpha are _much_ faster than on 1.6.

4) any debug libraries compiled in to gtk/glib/X/pcb/gschem etc? If you want the true meaning of slow, compile in ElectricFence to pcb or gschem (there is a configure flag to do it) and set the environment variables which give you the strictest checks. It gives new meaning to slow. Like running over a 1200 baud modem wouldn't hurt at that point.

5) how about any environment variables which may effect libc debugging? For example MALLOC_OPTIONS or /etc/malloc.conf can turn on various bits of malloc debugging on some operating systems. I've not checked, but I'll bet this impacts performance.

6) how are you on RAM? If you're on the edge, I could easily believe that going to gtk2 pushed you over on to the swapping a lot side.

7) what about your X server? I think various bits of gtk2 (I'm including things way down like pango, atk, freetype, etc) do much better or worse depending on things like your X server supporting or not supporting the RENDER extension. I shouldn't go any further than this because I've now said more than I know on that topic.

Anyway, I haven't noticed much of a slow down other than pcb taking slightly longer to load. But I have to admit I haven't been doing lots of layout just lately and haven't been doing large layouts lately either.

-Dan