[gst-devel] Re: Massive speed improvement in GObject type checking code

Owen Taylor otaylor at redhat.com
Sun Jun 17 14:53:28 CEST 2001


Tim Janik <timj at gtk.org> writes:

> On 17 Jun 2001, Owen Taylor wrote:
> 
> > Tim Janik <timj at 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




More information about the gstreamer-devel mailing list