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

["muppet" <scott asofyet org>]

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, throwing away the ability to fix bugs behind the scenes for a
negligible speed improvement.


-- 
muppet <scott at asofyet dot org>