Re: Performance data for nautilus

[Tim Janik <timj gtk org>]

On 18 Oct 2002, Sven Neumann wrote:

> Hi,
>
> Alexander Larsson <alexl redhat com> writes:
>
> > Very interesting. As usual it shows up GObject at its worst. I fixed a
> > leak in nautilus and a couple of places that were excessively typesafe,
> > but a lot of this is hard to fix.
> >
> > I've attached the interesting data for gtype.c. One thing that strikes me
> > is:
> >   * *********************************************************
> >   *  Function:                      g_type_check_instance_is_a
> >   *  Called:                          1106240 times
> >   *  Function time:                 121654830 cycles ( 2.25% of .root.)
> >   *  Function+descendants time:     344618647 cycles ( 6.37% of .root.)
> >   *  Distribution to Callers:
> >   *    203845 times (18.63% of f+d time) g_object_ref
> >   *    210290 times (19.22% of f+d time) g_object_unref
> >   * *********************************************************
> >
> > It seems a full 2.4% of the nautilus execution time is spent making sure
> > that what you pass to g_object_ref/unref() is actually GObjects.
> > I'm not sure it's really worth that. Maybe we should change G_IS_OBJECT to
> > g_type_fundamental (((GTypeInstance *)(instance))->g_class->g_type) ==
> > G_TYPE_OBJECT. Or maybe we should just totally dump the typecheck?
>
> shouldn't a production system have glib compiled with
> G_DISABLE_CAST_CHECKS anyway? I don't see why we should remove checks
> that might help developers if they can be easily disabled at compile
> time. Actually I have never understood why the extensive cast checks
> aren't disabled by default.

it's always easy to advocate removal of checks once your code is running.
the checks themselves are immensly helpfull
a) during development phase, you often get a WARNING/CRITICAL if
   you're using objects/glib/gtk the wrong way.
b) in rarely triggered code portions, where crashes are often still
   accompanied by assorted messages

if you don't consider (b) important enough, -DG_DISABLE_CAST_CHECKS is
a good idea for stable branches.

> Perhaps gtk+ and friends should even be
> compiled using G_DISABLE_CHECKS.

nope, definitely not, this renders everything return_if_fail() useless,
which is counter productive to developing an application against gtk.
if we did that, all that the ~6500 statements in glib/gtk serve for, is
the comparatively negligible benefit of checking project local consistency
during development phases.

>
> Salut, Sven

---
ciaoTJ