... of commit > > objects at all. > > Decompression speed has been shown to ... subsequent ones. I agree that zip time is an issue. I ... difficult tests. The approach you're taking (here and in following ... of being able to make zip/lzo selection and measure the ...

git - Dana How - Jan 10 2008 - 15:34

... and half of commit > objects at all. > > Decompression speed has been shown to be a ... a big already packaged but still not zipped file. Someone could be so kind to ... because as Junio pointed out the real decompressing schema is different: many calls on ...

git - Marco Costalba - Jan 10 2008 - 02:55

... slow to compress, high ratio but quick decompression: > > http://use.perl.org/~acme/journal/35330 ... check for repetiti= ve data, and even decompression needs quite a fair amount of ... be rather IO bound than CPU bound. LZO seems like a fai= rer choice, ...

git - Pierre Habouzit - Jan 10 2008 - 05:16

... huge blob (this applies > to both time and space). Yes - and lzo will almost certainly win on all those counts! I think to go ... the objects on disk which can be used to detect a gzip vs. an lzop stream. Not really worth it IMHO - gzip is already ...

git - Sam Vilain - Jan 9 2008 - 19:23

... .c > Looking at the git sources I have found that zip routines are candidate for a cleaning up, as example the ... where it is "really" intended as example archive-zip.c - Rename inflate()/deflate() and other zlib calls with corresponding ...

git - Marco Costalba - Jan 10 2008 - 07:45

... where it is "really" intended as example > archive-zip.c We have a long tradition to have the system includes in ... .h", what is the use of putting it also in archive-zip.c? Ciao, Dscho - To unsubscribe from this list: send the line " ...

git - Johannes Schindelin - Jan 10 2008 - 08:12

... a savings akin to bzip2 vs gzip, at the expense of ... -deltas. Well, interesting ideas anyway :) Subject: [PATCH] pack-objects: add compressionMinSize ... ,11 @@ pack.compression:: compromise between speed and compression (currently equivalent to ...

git - Sam Vilain - Jan 11 2008 - 21:52

"Marco Costalba" writes: > P.S: Compression size is better for zip but a more realistic test > would be to try with a delta packaged repo instead of a simple tar of > source files. Because delta packaged is already compressed in ...

git - Junio C Hamano - Jan 9 2008 - 18:55

... this today on an algorithm (LZMA - same as 7zip) which is very slow to compress, high ratio but quick decompression: http://use.perl.org/~acme/journal/35330 Which sounds excellent for squeezing those "archive packs" into even more ridiculously ...

git - Sam Vilain - Jan 10 2008 - 01:02

... would expect it to be rather IO bound than CPU > bound. LZO seems like a fairer choice, especially since what it makes ... are far from being the most frequently accessed objects. First they're clearly in minority, and often cached in the delta base ...

git - Nicolas Pitre - Jan 10 2008 - 16:39

... > The first thing I would like to test when zlib abstraction is ready is to test with NULL compressor, i.e. not compression/decompression at all and see if 'git log' and friends are happy. BTW would be possible to test git with zlib disabled also ...

git - Marco Costalba - Jan 10 2008 - 17:51

... thing I would like to test when zlib abstraction is ready is > to test with NULL compressor, i.e. not compression/decompression at > all and see if 'git log' and friends are happy. Easy: git config core.compression 0 Nicolas - To unsubscribe ...

git - Nicolas Pitre - Jan 10 2008 - 18:18

... wrong after all, and if a significant increase in access speed by avoiding zlib for 82% of object accesses can also be ... Right. But again this is not worth pursuing if a significant speed increase in repo access is not demonstrated at least with the ...

git - Nicolas Pitre - Jan 10 2008 - 17:30

... compression ratios. > and=20 > if a significant increase in access speed by avoiding zlib for 82% of=20 > object accesses can ... through a lot of small objects to see 10 to 20% increase speed (backed up by some experience I have in avoiding copies in ...

git - Pierre Habouzit - Jan 11 2008 - 04:57

... repack is a once time operation, but still, it > would speed up git gc --auto which is not something to neglect > ... Well, I was initially entousiastic about this avenue, but the speed performance difference is far from impressive IMHO, given the tradeoff ...

git - Nicolas Pitre - Jan 11 2008 - 10:27

... 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. For the ...

git - Junio C Hamano - Jan 9 2008 - 19:49

... all, which is 8% less time. I know it doesn't matters a lot as repack is a once time operation, but still, it would speed up git gc --auto which is not something to neglect completely. I say it's worth investigating a _lot_, and the patch is that ...

git - Pierre Habouzit - Jan 11 2008 - 05:45

... in order to make a gain somewhere else. The pack v4 format that I developed with Shawn, though, was showing _both_ a speed gain and a repository size reduction, hence there is no regression for the added improvements. *That* is a clear win. > We ...

git - Nicolas Pitre - Jan 12 2008 - 12:09

Hi, On Thu, 10 Jan 2008, Sam Vilain wrote: > 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

git - Johannes Schindelin - Jan 9 2008 - 19:31

On Wed, 9 Jan 2008, Johannes Schindelin wrote: > I agree that gzip is already fast enough. > > However, pack v4 had more goodies than just being faster; it also promised > to have smaller packs. Right, like not having to compress tree objects

git - Nicolas Pitre - Jan 9 2008 - 23:41