Re: Review of gnio, round 1
- From: Havoc Pennington <havoc pennington gmail com>
- To: Behdad Esfahbod <behdad behdad org>
- Cc: desrt desrt ca, gtk-devel-list <gtk-devel-list gnome org>, gicmo gnome org, Alexander Larsson <alexl redhat com>, danw gnome org
- Subject: Re: Review of gnio, round 1
- Date: Mon, 27 Apr 2009 11:40:42 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]