Re: git and larger trees, not so fast?

Linus Torvalds [off-list ref] writes:

On Sat, 11 Aug 2007, Fernando J. Pereda wrote:

quoted

quoted

What does "usable" mean? Is it still slow ("barely usable") or is it 
actually fast enough to be truly _nice_ to use?

Very nice to use considering my hardware is rather old. git status used
to take >1m and it now takes ~3s and git commit takes ~7s while it used
to take >1m too. So it makes things nice to use and I guess things are
MUCH better on faster hardware.

Oh, ok. Having a 7s commit sounds fine - certainly not instantaneous, but 
it doesn't sound too painful. Certainly not compared to what people live 
with normally in some other environments, at least.

Thanks go to moe for just giving a trivial script to reproduce the 
performance anomaly. It wasn't that hard to fix once there was a trivial 
and unambiguous test case.

Since one of the problems is git sorting stuff inefficiently, it might
make for an interesting test case to create the test files in reverse
alphabetic order so that readdir is more likely to deliver them in
reverse order, too.

Or in random order, by something like

dc -e '2 32^sb69069sc100000sd1se[rlc*le+lb%prle+dld!=a]sa42 0lax'|
while read i;do echo $i > $i;done

(change the 100000 to get a different number of files, change the
42 to get a different seed).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum