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

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Tue, 2005-12-13 at 15:40 -0500, muppet wrote:
> Gustavo J. A. M. Carneiro said:
> >   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?  Glib has many such small functions.
> 
> g_strdup() is a *very* poor example of a function that could be inlined for
> performance.  The function is trivial, yes, but it calls strlen(), malloc(),
> and memcpy() --- three operations which are going to swamp the time spent in
> making a call to a real symbol for g_strdup().  This would be a misguided
> optimization,

  OK, I just made one mistake: I forgot that strlen and memcpy are
already inlined, so that function in particular turned out not to be so
small :P

  Some examples of really tiny functions are g_list_find, g_list_length,
g_ascii_dtostr.  About half a dozen assembly instructions (on x86) each.

>  throwing away the ability to fix bugs behind the scenes

  I meant this only for functions that are trivial; do you think there's
any chance for anyone ever spot a bug in g_strdup?

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic