Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
- From
- Dana How <danahow@gmail.com>
- Date
- May 4, 2007, 16:10 UTC
- Message-ID
- <56b7f5510705040910i3cac723co3aed45034c097def@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.0.99.0705040937250.24220@xanadu.home>
On 5/4/07, Nicolas Pitre <nico@cam.org> wrote:
Show 24 quoted lines
> On Thu, 3 May 2007, Junio C Hamano wrote: > > > "Dana How" <danahow@gmail.com> writes: > > > > > So for a 25% increase in blob size I get 33% less elapsed time > > > in git-add, all by changing core.compression from -1 to 1. > > > I'll definitely take that improvement. [For the compressible files > > > we typically have, using 0 is a bad idea: the CPU "advantage" > > > is swamped out by the time to write a much larger file.] > > > > The above number is about loose objects, right? > > > > > Since I don't care [to the same degree] about the responsiveness of > > > packing, I'd rather pack with -1 or better to keep packs small. > > > > I see. You are saying that the fact that core.compression is > > used also for packing makes the variable less useful. > > I think that would make sense to have separate configs for pack and > loose object compression. When not specified they should simply default > to core.compression if it exists. Otherwise I'd suggest that pack > compression default level be Z_DEFAULT_COMPRESSION and loose object > compression default level be Z_BEST_SPEED. This would make interactive > operations like git-add and git-commit even faster by default.
I agree with your Z_BEST_SPEED idea. I did not include it in the patch b/c I didn't want to change any behavior in the absence of new config settings.
Are you actually arguing for *3* different compression-related config variables? How about: (a) core.compression controls loose objects. defaults to Z_BEST_SPEED. (b) pack.compression controls packing. defaults to Z_DEFAULT_COMPRESSION if neither variable exists. defaults to core.compression if only that exists
The last sentence mimics current behavior and to me seems least surprising. Or pack.compression could be simpler: default to Z_DEFAULT_COMPRESSION if pack.compression doesn't exist (no interaction with core.compression).
Thanks,
-- Dana L. How danahow@gmail.com +1 650 804 5991 cell