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

[Balazs Scheidler <bazsi balabit hu>]

On Tue, 2005-12-13 at 22:13 +0100, Tim Janik wrote:
> On Tue, 13 Dec 2005, Gustavo J. A. M. Carneiro wrote:
> 
> > Ter, 2005-12-13 às 17:11 +0100, Tim Janik escreveu:
> >
> >  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.

I personally would not say to inline every trivial function in GLib, I
was talking about single-instruction functions that are not inlined
right now, it might even be possible that the call instruction itself is
longer than the instruction itself, not to mention that functions linked
in from shared libraries jump twice to reach the actual body of the
function. (first call to a stub which jumps to the function itself), so
it effectively empties the instruction pipeline twice.

Nevertheless I shut up and post patches :) Thanks for the information
and sorry for the noise.

-- 
Bazsi