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

[Tim Janik <timj gtk org>]

On Tue, 13 Dec 2005, Gustavo J. A. M. Carneiro wrote:

> Ter, 2005-12-13 às 17:11 +0100, Tim Janik escreveu:

> > 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.
>
>  IMHO, some functions are obvious candidates for inlining, regardless
> of any profiling done on them.  For instance:
>
> gchar*
> g_strdup (const gchar *str)
> {
>  gchar *new_str;
>  gsize length;
>
>  if (str)
>    {
>      length = strlen (str) + 1;
>      new_str = g_new (char, length);
>      memcpy (new_str, str, length);
>    }
>  else
>    new_str = NULL;
>
>  return new_str;
> }
>
> This function is trivial.  I doubt you'll ever find any new bugs in it.
> It is called in many places.  So why pay a performance penalty when you
> could easily avoid it?

inlining doesn't automatically mean performance improvements and
not inlining doesn't automatically cause performance penalties.

if you start to inline lots of widely used small functions in
non performance critical code sections, all you've gained is a
bigger code section size and less likelyness for warm instruction
caches (that becomes especially critical when starting to bloat
tight loops due to inlining).
now consider that 90% of a programs runtime is spent in 10% of its
code, that means 90% of your inlininig does ocoour in non performance
critical sections.
that's why modern compilers use tunable heuristics to decide about
automated inlining and don't stupidly inline everything they can.

what you're suggesting is blind optimization, experienced programmers
will tell you that this will result in more harm than good. profiling
a critical section, and maybe inlining/optimizing a single string
copy in a critical loop can gain you ten- or hundredfold the improvements
that you could get from some shallow global optimization.

you don't even need to believe me, just start googling for
"premature" and "optimization" and read, there's enough stuff
out there to make your christmas holidays ;)


>  Glib has many such small functions.
>
> [ BTW, "if (str)" could be changed to "if (G_LIKELY(str))" ]

yes it could, and it would make sense. the best thing you can do to
make sure such improvements are integrated, is to submit complete
patches for such changes (including changelog entries) so we only
need to apply, compile and test them and are done.
(and if you have/need commit access, after a number of quality
submissions that is usually granted because it can save us
additional work.)


>  One other thing; it is well known that inline functions are better
> than macros:
> 	- Give you better type safety;
> 	- Less cryptic warnings/errors when calling them with wrong types
> 	- For debugging, you can still disable inlining through the CFLAGS in
> order to "step into" the inline functions in step by step debugging;
>
>  So why not start using less macros and more inline functions?

well, we're not completely unaware of the type safety inline functions
can offer over some macros uses ;)

why don't you start to submit patches for macros where you think we
really should have used an inlined function and we discuss specific
cases then?

you can take a look at the existing glib headers to see how we do inlined
functions, and read the comments which describe how inlined functions
still are built in a non-inlined version into glib.

> --
> Gustavo J. A. M. Carneiro

---
ciaoTJ