Re: Review of gnio, round 1

On 04/27/2009 11:40 AM, Havoc Pennington wrote:

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.


But somebody should probably ask some gcc gurus


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]