Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N

["Dana How" <danahow@gmail.com>]

On 5/3/07, Junio C Hamano <junkio@cox.net> 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?
Correct.

> > 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.
Exactly.

> I agree that it would make sense to have at least the pack and
> core compression independent.  I am not sure if we would also
> want to make the pack compression tweakable depending on the
> purpose of the packing (network transfer vs .git/objects/pack/).
The final 12-line hunk in the patch implements --pack-compression=N.
To be blunt,  I'm not sure *I* need it.  Perhaps a high-use web-accessible
public repository would be interested in repacking off-line with 9,  and
creating packs for each puller using -1 to reduce CPU load.  In the latter
case,  due to builtin-pack-objects.c:write_object():to_reuse==1,
much of the transferred data would still be at the better compression
but without again paying the CPU cost.  Shall I remove it?

BTW, I'm now in the habit of browsing Git's Gitweb at git.or.cz and notice
"pu" has --max-pack-size.  You may want to upgrade to the last 5-patch
version in which --max-pack-size no longer forces --no-reuse-delta at
Shawn's request,  among other clean-ups.

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell