Stefan Sperling:

>   git clone --bare https://git.torproject.org/tor.git
>   cd tor.git && got log -l1 -p -c 9c83cd1993b6ed98301020e5a170df9d5427a1e6
> 
> Diffing this commit currently takes a very long time.
> 
> This limits the upwards search to 1000 lines, and searches just the
> first byte of each line being scanned.

Yes to the first-byte optimization.

I suspect the problem isn't that we scan back thousands of lines,
but that we do so thousands of times.  GNU diff caches the last
function prototype and the line number from which it started
searching.  The next time it will only scan back as far as that
line number; if it hasn't found a prototype, it will reuse the
cached one and update the line number.  Is that an approach we could
use?

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de