Thread (54 messages) flat view 54 messages, 11 authors, 2018-09-02

Re: [ANNOUNCE] Git v2.19.0-rc0

From: Jeff King <hidden>
Date: 2018-08-23 02:16:21

On Wed, Aug 22, 2018 at 06:23:43PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
quoted
quoted
On Tue, 2018-08-21 at 23:03 -0400, Jeff King wrote:
quoted
quoted
quoted
 static inline int hashcmp(const unsigned char *sha1, const unsigned
char *sha2)
 {
+       assert(the_hash_algo->rawsz == 20);
        return memcmp(sha1, sha2, the_hash_algo->rawsz);
 }
[...]
quoted
             The bigger questions are:

  - are we OK with such an assertion; and

  - does the assertion still give us the desired behavior when we add in
    a branch for rawsz==32?

And I think the answers for those are both "probably not".
At this point in the release process, I think the answer to the first
question is a pretty clear "yes".

A ~10% increase in latency of some operations is quite significant, in
exchange for no user benefit yet.  We can continue to try to figure
out how to convince compilers to generate good code for this (and
that's useful), but in the meantime we should also do the simple thing
to avoid the regression for users.
FWIW, it's not 10%. The best I measured was ~4% on a very
hashcmp-limited operation, and I suspect even that may be highly
dependent on the compiler. We might be able to improve more by
sprinkling more asserts around, but there are 75 mentions of
the_hash_algo->rawsz. I wouldn't want to an assert at each one.

I don't mind doing one or a handful of these asserts as part of v2.19 if
we want to try to reclaim those few percent. But I suspect the very
first commit in any further hash-transition work is just going to be to
rip them all out.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help