no reply patch

[dormando]

Tomash Brechko wrote:
> On Tue, Feb 19, 2008 at 00:44:26 -0800, dormando wrote:
>> For sanity I'm going to have to change it to look like this:
>>
>>     if (c->noreply) {
>>         if (settings.verbose > 1)
>>             fprintf(stderr, ">%d NOREPLY %s\n", c->sfd, str);
>>         c->noreply = false;
>>         conn_set_state(c, conn_read);
>>         return;
>>     }
> 
> Ok, no objections.
> 
> 
>> ...and for both of these, the test should be 'if unlikely(c->noreply)' -
> 
> It hardly would make any difference, we are not in a tight loop.  You
> could also write unlikely(settings.verbose > 1), but I'd say one
> should save such optimizations to places there they do make noticeable
> speedup.  OTOH, I guess GCC's __builtin_expect() may suggest the
> compiler to reverse the order of branches.

I've been thinking of adding unlikely for all of the verbosity checks in
a separate patch...
Unless I'm mistaken this optimization is expressly for big loops. In a
tight loop modern CPU's have a small branch prediction history (I forget
the actual term for it) and would get a speedup. In longer flat loops
the obvious branch miss won't likely be cached. Yeah, it's minor, but
optimizing everything is a theme here!

> As was mentioned before, the problem is not limited to 'noreply' only.
> Send to memcached "SET KEY\r\nVALUE\r\n" (in upper case), and enjoy
> two replies instead of one.  With 'norepy' it's just one reply instead
> of zero, same problem.  And this can only happen for malformed
> command, where error reply is send before the command has been parsed
> (memcached couldn't parse it).

SIGH, ALL RIGHT :) I'm going to start logging the questions I get :)

-Dormando