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

2005-12-14 Thread Balazs Scheidler
On Tue, 2005-12-13 at 22:13 +0100, Tim Janik wrote: > On Tue, 13 Dec 2005, Gustavo J. A. M. Carneiro wrote: > > > Ter, 2005-12-13 às 17:11 +0100, Tim Janik escreveu: > > > > IMHO, some functions are obvious candidates for inlining, regardless > > of any profiling done on them. For instance: > >

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

2005-12-13 Thread Gustavo J. A. M. Carneiro
On Tue, 2005-12-13 at 18:12 -0500, muppet wrote: > Gustavo J. A. M. Carneiro said: > > On Tue, 2005-12-13 at 15:40 -0500, muppet wrote: > >> 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 a

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

2005-12-13 Thread muppet
Gustavo J. A. M. Carneiro said: > On Tue, 2005-12-13 at 15:40 -0500, muppet wrote: >> 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? You already did --- the

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

2005-12-13 Thread Gustavo J. A. M. Carneiro
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 leng

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

2005-12-13 Thread Alan M. Evans
On Tue, 2005-12-13 at 10:10, Gustavo J. A. M. Carneiro wrote: > This function is trivial. I doubt you'll ever find any new bugs in it. [...] > [ BTW, "if (str)" could be changed to "if (G_LIKELY(str))" ] Think about this. -- Alan M. Evans <[EMAIL PROTECTED]>

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

2005-12-13 Thread Tim Janik
On Tue, 13 Dec 2005, Gustavo J. A. M. Carneiro wrote: Ter, 2005-12-13 às 17:11 +0100, Tim Janik escreveu: 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 mac

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

2005-12-13 Thread muppet
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; >

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

2005-12-13 Thread Gustavo J. A. M. Carneiro
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 +, 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 poss

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

2005-12-13 Thread Tim Janik
On Mon, 12 Dec 2005, Balazs Scheidler wrote: On Mon, 2005-12-12 at 18:44 +, 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 muc

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

2005-12-12 Thread Balazs Scheidler
On Mon, 2005-12-12 at 18:44 +, 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-instruc

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

2005-12-12 Thread Gustavo J. A. M. Carneiro
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