Re: inlining glib functions (Was: public barrier functions)

[Tim Janik <timj imendio com>]

On Mon, 12 Dec 2005, Balazs Scheidler wrote:

> On Mon, 2005-12-12 at 18:44 +0000, Gustavo J. A. M. Carneiro wrote:
> > Seg, 2005-12-12 às 19:29 +0100, Balazs Scheidler escreveu:
> > [...]
> > > And while I am at it, would it be possible to change the atomic
> > > operations to inline functions? I'd think it is much better inline
> > > single-instruction functions as otherwise the call overhead is too
> > > great.
> >
> >   I agree.  Also many other glib functions could be static inline in the
> > public header files.  For instance, many of the functions in glist.c and
> > gslist.c are really tiny, thus could easily be inlined, but aren't
> > because the compiler has no access to their implementation, only to
> > their prototype.
>
> One problem I see with this is binary compatibility. The shared lib
> version of glib has to provide the old non-inlined symbols, and simply
> moving the functions to the header as "static inline" would remove those
> symbols, even though I would not be surprised if this could be worked
> around with some gcc trickery, something along the lines of:

we already have the machnism to compile a non inlined version and
provide a symbol for functions which are possibly defined as static inline
in the header files.

more important than _how_ to inline is _what_ and _why_ to inline.
in general, things that can easily and reasonably be inlined have been
already been provided as inlined functions or macros in the glib headers.
so for functions that are not inlined but you think _should_ be inlined,
a persuasive argument should be given, e.g. a profiling scenario where the
function in question shows up with significant figures and significant
timing improvements for using the inlined version.
the g_atomic_* functions are a good example of this (see profiling figures
mentioned in the original thread), but they are still not inlined for other
reasons.

> --
> Bazsi

---
ciaoTJ