Re: Massive speed improvement in GObject type checking code

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Mon, 18 Jun 2001, Alex Larsson wrote:
> 
> > On Sun, 17 Jun 2001, Tim Janik wrote:
> > 
> > > > 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.
> > 
> > I'd like to point out here that GCC produces better code for macros than
> > inline functions. This will continue to be true in GCC 3.0, and in the
> > future until the tree inliner is ported from the c++ compiler to the c
> > compiler.
> 
> well, for gcc you can use the ({ TYPE var = (arg); retval; }) extension,
> if that produces better code than using static inline instead, feel
> free to provide a gcc-special cased patch, once we have the static inlines ;)

'static inline' is, of course, very much a GCC extension.

                                        Owen