Re: git and larger trees, not so fast?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> On Sat, 11 Aug 2007, Fernando J. Pereda wrote:
>> > 
>> > 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux