Re: [PATCH] git gc: Speed it up by 18% via faster hash comparisons
- From
Erik Faye-Lund <kusmabite@gmail.com>
- Date
- Apr 28, 2011, 12:40 UTC
- Message-ID
- <BANLkTi=6zzW41OagqAQfifHfQ4Mvy+BwsA@mail.gmail.com>
- In-Reply-To
- <20110428123617.GA2062@elie>
On Thu, Apr 28, 2011 at 2:36 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 33 quoted lines
> Hi,
>
> A side note for amusement.
>
> Erik Faye-Lund wrote:
>
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -681,13 +681,17 @@ extern char *sha1_pack_name(const unsigned char *sha1);
>> extern char *sha1_pack_index_name(const unsigned char *sha1);
>> extern const char *find_unique_abbrev(const unsigned char *sha1, int);
>> extern const unsigned char null_sha1[20];
>> -static inline int is_null_sha1(const unsigned char *sha1)
>> +static inline int hashcmp(const unsigned char *sha1, const unsigned char *sha2)
>> {
>> - return !memcmp(sha1, null_sha1, 20);
>> + /* early out for fast mis-match */
>> + if (*sha1 != *sha2)
>> + return *sha1 - *sha2;
>> +
>> + return memcmp(sha1 + 1, sha2 + 1, 19);
>> }
>
> On the off-chance that sha1 and sha2 are nicely aligned, a more
> redundant
>
> if (*sha1 != *sha2)
> return *sha1 - *sha2;
>
> return memcmp(sha1, sha2, 20);
>
> would take advantage of that (yes, this is just superstition, but it
> somehow seems comforting anyway).Good point, I think that's an improvement.
> Anyway, assuming it does not kill performance for some reason, the > above sounds good to me. Thanks for spelling it out.
If it does, then we haven't fully understood where it came from in the first place, no? :P