On Tue, Aug 08, 2017 at 10:36:33PM -0700, Junio C Hamano wrote: > > Actually, I take it back. The problem happens when we enter the loop > > with no entries to look at. But both sha1_pos() and sha1_entry_pos() > > return early before hitting their do-while loops in that case. > > Ah, I was not looking at that part of the code. Thanks. > > I still wonder if we want to retire that conditional invocation of > sha1_entry_pos(), though. I think so. Digging in the list for it, almost every mention is either somebody asking "should we scrap this?" or somebody showing benchmarks in which it is slower than the normal lookup (and then somebody asking "should we scrap this" :) ). I just re-ran a simple benchmark and it is indeed slower. I also came across the hashcmp open-code-versus-memcmp discussion, which shows that the memcmp in recent glibc is much faster. That has been around long enough that it's probably worth switching to. -Peff
