From: Sam Vilain Date: Wed, 09 Jan 2008 23:23:17 GMT Subject: Re: Decompression speed: zip vs lzo Message-ID: <47855765.9090001@vilain.net> In-Reply-To: <7v4pdmfw27.fsf@gitster.siamese.dyndns.org> Junio C Hamano wrote: > Note that the space nor time performance of compressing and > uncompressing a single huge blob is not as interesting in the > context of git as compressing/uncompressing millions of small > pieces whose total size is comparable to the specimen of "huge > single blob" experiment. Obviously loose object files are > compressed individually, and packfile contents are also > individually and independently compressed. Set-up cost for > individual invocation of compression and uncompression on > smaller data matters a lot more than an experiment on > compressing and uncompressiong a single huge blob (this applies > to both time and space). Yes - and lzo will almost certainly win on all those counts! I think to go forward this would need a prototype and benchmark figures for things like "annotate" and "fsck --full" - but bear in mind it would be a long road to follow-up to completion, as repository compatibility would need to be a primary concern and this essentially would create a new pack type AND a new *object* type. Not only that, but currently there is no header in the objects on disk which can be used to detect a gzip vs. an lzop stream. Not really worth it IMHO - gzip is already fast enough on even the most modern processor these days. Sam.