Re: git-index-pack really does suck..

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

 




On Tue, 3 Apr 2007, Nicolas Pitre wrote:
> > 
> > It could be as simple as just the index file itself. That's 11MB for the 
> > kernel. Imagine if the index file was 20 times bigger - 200MB of memory 
> > paged in with bad access patterns just for unnecessary lookups.
> 
> Again that presumes you have to page in the whole index, which should 
> not happen when pulling (much smaller packs) and with a better lookup 
> algorithm.

Actually, since SHA1's are randomly distributed, together with the binary 
search, you probably *will* pull in the bulk of the index, even with a 
fairly small set of SHA1's that you check.

> Make it conditionnal on --stdin then.  This covers all cases where we 
> really want the secure thing to happen, and the --stdin case already 
> perform the atomic rename-and-move thing when the pack is fully indexed.

I don't care *what* it is conditional on, but your arguments suck. You 
claim that it's not a normal case to already have the objects, when it 
*is* a normal case for alternates, etc.

I don't understand why you argue against hard numbers. You have none of 
your own.

		Linus
-
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]