Re: Review of gnio, round 1

[Havoc Pennington <havoc pennington gmail com>]

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"

But somebody should probably ask some gcc gurus

Havoc