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.