From 0b006014c87f400bd9a86267ed30fd3e7b383884 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Wed, 9 Aug 2017 06:16:45 -0400 Subject: [PATCH] hashcmp: use memcmp instead of open-coded loop In 1a812f3a70 (hashcmp(): inline memcmp() by hand to optimize, 2011-04-28), it was reported that an open-coded loop outperformed memcmp() for comparing sha1s. Discussion[1] a few years later in 2013 showed that this depends on your libc's version of memcmp(). In particular, glibc 2.13 optimized their memcmp around 2011. Here are current timings with glibc 2.24 (best-of-five, on linux.git): [before this patch, open-coded] $ time git rev-list --objects --all real 0m35.357s user 0m35.016s sys 0m0.340s [after this patch, memcmp] real 0m32.930s user 0m32.630s sys 0m0.300s Now that we've had 6 years for that version of glibc to make its way onto people's machines, it's worth revisiting our benchmarks and switching to memcmp(). It may be that there are other non-glibc systems where memcmp() isn't as well optimized. But since our single data point in favor of open-coding was on a now-ancient glibc, we should probably assume the system memcmp is good unless proven otherwise. We may end up with a SLOW_MEMCMP Makefile knob, but we can hold off on that until we actually find such a system in practice. [1] https://public-inbox.org/git/20130318073229.GA5551@sigill.intra.peff.net/ Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- cache.h | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/cache.h b/cache.h index 900796c155..5688b263e4 100644 --- a/cache.h +++ b/cache.h @@ -962,14 +962,7 @@ extern const struct object_id null_oid; static inline int hashcmp(const unsigned char *sha1, const unsigned char *sha2) { - int i; - - for (i = 0; i < GIT_SHA1_RAWSZ; i++, sha1++, sha2++) { - if (*sha1 != *sha2) - return *sha1 - *sha2; - } - - return 0; + return memcmp(sha1, sha2, GIT_SHA1_RAWSZ); } static inline int oidcmp(const struct object_id *oid1, const struct object_id *oid2) -- 2.11.4.GIT