Re: GObject is slow

[Owen Taylor <otaylor redhat com>]

Pavel Cisler <pavel eazel com> writes:

> Alexander Larsson wrote:
> > 
> > On 20 Nov 2000, Owen Taylor wrote:
> > 
> > >
> > > Alexander Larsson <alla lysator liu se> writes:
> > >
> > > > I've been doing some profiling of GtkFB to find out bottlenecks in the
> > > > rasterization code. But looking at the profiles show that rasterization
> > > > isn't even at the top. Instead i see a lot of functions from the GObject
> > > > type checking code.
> > > >
> > > > Here is the top of a profile on a testgtk run using GtkFB @ 1024x768
> > > > 16bit. glib+pango+gtk+ is compiled with -O2 -g  and -DG_DISABLE_ASSERT
> > > > -DG_DISABLE_CHECKS -DGTK_NO_CHECK_CASTS.
> > >                      ^^^^^^^^^^^^^^^^^^^^
> > >
> > > I think you'll see better results if you use G_DISABLE_CAST_CHECKS -
> > > all the stuff at the top of your profile except for the rendering
> > > code seems to be cast checks...
> > 
> > Oops. I wonder where i got GTK_NO_CHECK_CASTS from?
> > 
> > > (Not that it wouldn't be good if GTK+ was fast even with checking
> > > turned on.)
> > Agree.
> > 
> > > Regards,
> > >                                         Owen
> > >
> > > [ Also, could you put the full profile results up somewhere - its a
> > >   bit hard for me to make sense of the straight profile without
> > >   the call graph info ]
> > 
> > Here is the full straight profile:
> > http://www.lysator.liu.se/~alla/files/profile_1.txt
> > 
> > Unfortunately there is no call graph info, since this was done using the
> > eazel-profiler, which doesn't generate that. I'm actively working on
> > making it better though, so I'll add that in the future. Unfortunately
> > I'm a bit blocked by two compiler bugs I found concerning
> > -finstrument-functions... Just waiting for Jakub to fix them :)
> 
> I could put in the call graph info support pretty easily. I omitted it
> for now because it is a lot of output (in the case of a larger app like
> Nautilus, anyhow) and it wasn't as useful as the timing/percentage
> table.

It's pretty big for a large toolkit like GTK+ too ;-) But then
I tend to expect that.

While you can usually reverse-engineer the call-graph information
by looking at the code if you are familiar enough with the 
way the program works, I find it useful in figuring out the
large scale optimizations of _why_ functions are getting called
a lot of times, instead of simple which functions are getting
called a lot.

(Although if the call graph information could skip GtkSignal
emission stack frames, it would be a lot _more_ useful. Though
this is most likely hard to do without completely killing
the performance of the profiler.)

Plus, if someone wrote a tool to analyze profile outputs and display
them in a nice graphical way (at least as good as memprof or better)
then you'd really want the call graph info there.

Regards,
                                        Owen