Re: GObject is slow

[Alexander Larsson <alla lysator liu se>]

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 :)

/ Alex