Re: GObject is slow

[Pavel Cisler <pavel eazel com>]

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.

Pavel