Jeff King <> writes:

> I do not see anything obviously wrong in it, though I did not walk
> through all of the ofs calculation to look for any clever speedups.
> However, I think it is clear from the other timings and Ingo's thread
> that glibc 2.11's memcmp does not perform very well on many short reads.
> And sha1_entry_pos will do memcmps even smaller than 20 bytes.
> What happens if you do this?

The overall trend is the same.

[without GIT_USE_LOOKUP]
real    0m40.044s
real    0m40.054s
real    0m40.072s
real    0m40.097s
real    0m40.159s

real    0m40.257s
real    0m40.281s
real    0m40.311s
real    0m40.366s
real    0m40.407s

I suspect that after the first few rounds the range shrinks small
enough that the difference between a simple "mi = (hi + lo)/2" and
convoluted ofs computation becomes dominant.  Perhaps we should only
do N-R for the initial midpoint selection and then fall back to a
stupid binary search?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to