Re: Massive speed improvement in GObject type checking code

[Tim Janik <timj gtk org>]

On 17 Jun 2001, Owen Taylor wrote:

> 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.

i don't think there's much to worry about compilers that can't inline
nowadays. glib ensures that static inline at least works on such systems
by providing a non-static linkable version, if static inline isn't supported.
so worst-case scenario is that for inline-incapable compilers an extra
function call is performed.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ