On 5/4/07, Nicolas Pitre <nico@xxxxxxx> wrote:
On Thu, 3 May 2007, Junio C Hamano wrote: > "Dana How" <danahow@xxxxxxxxx> 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@xxxxxxxxx +1 650 804 5991 cell - 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