Jeff King <p...@peff.net> writes:
> Here are numbers for p0001.2 run against linux.git on a few
> versions. This is using -O2 with gcc 8.2.0.
>
> Test v2.18.0 v2.19.0-rc0 HEAD
>
> ------------------------------------------------------------------------------
> 0001.2: 34.24(33.81+0.43) 34.83(34.42+0.40) +1.7% 33.90(33.47+0.42)
> -1.0%
I see what you did to the formatting here, which is a topic of
another thread ;-).
Thanks, as Derrick also noted, I agree this is an appropriate
workaround for the upcoming release and we may want to explore
hasheq() and other solutions as part of the effort during the next
cycle (which can start now if people are bored---after all working
on the codebase is the best way to hunt for recent bugs).
Thanks, will queue.
> diff --git a/cache.h b/cache.h
> index b1fd3d58ab..4d014541ab 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1023,6 +1023,16 @@ extern const struct object_id null_oid;
>
> static inline int hashcmp(const unsigned char *sha1, const unsigned char
> *sha2)
> {
> + /*
> + * This is a temporary optimization hack. By asserting the size here,
> + * we let the compiler know that it's always going to be 20, which lets
> + * it turn this fixed-size memcmp into a few inline instructions.
> + *
> + * This will need to be extended or ripped out when we learn about
> + * hashes of different sizes.
> + */
> + if (the_hash_algo->rawsz != 20)
> + BUG("hash size not yet supported by hashcmp");
> return memcmp(sha1, sha2, the_hash_algo->rawsz);
> }
