Re: Review of gnio, round 1

[Behdad Esfahbod <behdad behdad org>]

On 04/27/2009 11:40 AM, Havoc Pennington wrote:
> Hi,
>
> On Mon, Apr 27, 2009 at 10:40 AM, Behdad Esfahbod<behdad behdad org>  wrote:
> > > There is a lot of G_UNLIKELY() calls in places that really are not in
> > > any way performance sensitive. I'm not sure I like this, since it makes
> > > the code harder to read for very little gain. Like, it probably makes
> > > sense for the inlined version of g_once_init_enter() to use G_LIKELY,
> > > but I don't think it makes sense for e.g. error checking when creating a
> > > socket, which is not gonna happen a lot.
> > I think I can answer this part since I use G_UNLIKELY extensively myself.
> >   The way I see it, it's not just a hint for the compiler, it's also an
> > annotation of the source code for the next person reading it, saying "this
> > branch is expected to happen in exceptional cases only, not the norm."  And
> > I find it extremely useful for that.
>
> I don't really know much about modern processors or compilation, but
> my understanding is that the penalty for being wrong on G_UNLIKELY()
> is quite high. And as we know from the old "premature optimization"
> cliche it can be a bit hard to predict which codepaths get hit. For
> example, I can certainly imagine uses of IO or socket APIs where IO
> errors are hit reasonably often.
>
> I thought G_UNLIKELY was really exclusively for cases where we "know"
> the unlikely case will almost never be hit, like one-time
> initialization, and that it was discouraged in cases where it's just
> probabilistic, like "this is probably a bit less common"

My use case is mostly for 1) programmer errors, and 2) alloc failure errors. 
Both of which are safe to assume they never happen.

behdad

> But somebody should probably ask some gcc gurus
>
> Havoc