Re: Massive speed improvement in GObject type checking code
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Erik Walthinsen <omega temple-baptist com>, gtk-list redhat com, Gtk+ Developers <gtk-devel-list gnome org>, gstreamer-devel lists sourceforge net
- Subject: Re: Massive speed improvement in GObject type checking code
- Date: 17 Jun 2001 08:53:28 -0400
Tim Janik <timj gtk org> writes:
> On 17 Jun 2001, Owen Taylor wrote:
>
> > Tim Janik <timj gtk org> writes:
>
> > > however, considering the speed advatage you report, it might be worth
> > > lessening the guarantees that G_TYPE_CHECK_INSTANCE_TYPE() makes, so that,
> > > for the supposedly pathological case that the instance is broken in that
> > > its class contains a non-registered type-id, _and_ this non-registered
> > > type id is being checked for, it returns a false TRUE.
> > >
> > > we still need to get around the double evaluation of the (ip) arg of
> > > _G_TYPE_CIT() though, so we'd have to implement it via an auxillary
> > > static inline function.
> > > the same kind of optimization can be implemented for the class
> > > type-checking macro btw.
> >
> > It's interesting to note that macros such as GTK_OBJECT() have double
> > evaluated for a long time, and nobody has ever noticed/complained.
>
> that's why i said "potentially" harmfull ;)
> i'm sure you agree that we still need to avoid doubleeval, right?
I'm not sure. Considering that inline functions in C or statement
expressions aren't portable, and I think GObject should probably
perform portably, it's conceivable that the danger is worth it.
I think it was worth it for the GTK_OBJECT() macro.
It would certainly be good to avoid double evals for cast macros
if at all possible. I've certainly written:
GTK_ADJUSTMENT (gtk_adjustment_new (...));
Once or twice.
Double evals are less harmful for BLAH_IS_FOO() as compared to
BLAH_FOO(), because the worst that can happen with a double eval in
BLAH_IS_FOO() is a bit of inefficiency - a memory leak can't happen
because the instance pointer isn't returned.
And aren't very likely to write something along the lines:
if (PANGO_IS_LAYOUT (gtk_label_get_layout (label))
layout = gtk_label_get_layout (label);
But any time a double eval of a macro can be avoided, the better,
of course.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]