Re: Decompression speed: zip vs lzo

From: Nicolas Pitre <nico@cam.org>
Date: Jan 12, 2008, 16:09 UTC
Message-ID: <alpine.LFD.1.00.0801121053080.3054@xanadu.home>
In-Reply-To: <47882EC5.2080406@vilain.net>

On Sat, 12 Jan 2008, Sam Vilain wrote:

Show 13 quoted lines

> Nicolas Pitre wrote:
> > Sorry to rain on your parade, but to me 6-10% time saving is not a clear 
> > win at all, given the equal increase in repository size.  This is simply 
> > not worth it.
> 
> Agree.
> 
> > And a 50% time saving on an operation, such a git log, which takes less 
> > than 2 seconds in absolute time, is not worth the repo size increase 
> > either.
> 
> Disagree.  Going as much as twice as fast for many history operations
> for 10% added space sounds like a clear win to me.

If you can come with a real life scenario, and not simply a simple test having little relevance with typical usage, that shows a clear reduction in execution time which is human perceptible, then I'll agree with you. But doing a full history log taking one second instead of two isn't a good enough argument to me for making the repository many megabytes larger. Again if it was 'git blame' using 5 seconds instead of 10 then I would agree that this is a clear win, even if this is also a 50% execution time reduction. But human perception is way more important when it is 10 secs down to 5 compared to 2 secs down to 1.

This proposed change isn't free, because you have to introduce a regression in one place 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 can easily agree
> to disagree though

I suppose we do.

Nicolas