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