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