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



Ter, 2005-12-13 às 17:11 +0100, Tim Janik escreveu:
> 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.

  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.

[ BTW, "if (str)" could be changed to "if (G_LIKELY(str))" ]

  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?

  Of course, when a function uses data types, functios or variables that
are private to GLib, then inlining cannot be done, but some other
functions are tiny and only use public APIs, so...

  Regards.

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

Attachment: signature.asc
Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]