From: Jeff King <peff@peff.net>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Duy Nguyen <pclouds@gmail.com>,
Martin Fick <mfick@codeaurora.org>,
Git List <git@vger.kernel.org>
Subject: Re: [PATCH] git exproll: steps to tackle gc aggression
Date: Fri, 9 Aug 2013 07:00:00 -0400 [thread overview]
Message-ID: <20130809110000.GD18878@sigill.intra.peff.net> (raw)
In-Reply-To: <CALkWK0=nerszb3_YA8P=qXbfAd4Y1rNsHXhfVKzwtj-x80iqkg@mail.gmail.com>
On Fri, Aug 09, 2013 at 01:34:48AM +0530, Ramkumar Ramachandra wrote:
> Certainly. A push will never use an existing pack as-is, as it's very
> highly unlikely that the server requested exactly what gc --auto
> packed for us locally.
>
> Sure, undeltified objects in the pack are probably better for push
> performance, but I'm talking about the majority: deltified objects.
> Don't you need to apply the deltas (ie. explode the pack), before you
> can recompute the deltas for the information you're sending across for
> the push?
It depends on what each side has it, doesn't it? We generally try to
reuse on-disk deltas when we can, since they require no computation. If
I have object A delta'd against B, and I know that the other side wants
A and has B (or I am also sending B), I can simply send what I have on
disk. So we do not just blit out the existing pack as-is, but we may
reuse portions of it as appropriate.
Of course we may have to reconstruct deltas for trees in order to find
the correct set of objects (i.e., the history traversal). But that is a
separate phase from generating the pack's object content, and we do not
reuse any of the traversal work in later phases.
-Peff
next prev parent reply other threads:[~2013-08-09 11:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-06 2:38 [PATCH] git exproll: steps to tackle gc aggression Ramkumar Ramachandra
2013-08-06 12:24 ` Duy Nguyen
2013-08-06 17:39 ` Junio C Hamano
2013-08-07 4:43 ` Ramkumar Ramachandra
2013-08-08 7:13 ` Junio C Hamano
2013-08-08 7:44 ` Ramkumar Ramachandra
2013-08-08 16:56 ` Junio C Hamano
2013-08-08 17:34 ` Martin Fick
2013-08-08 18:52 ` Junio C Hamano
2013-08-08 19:14 ` Ramkumar Ramachandra
2013-08-08 17:36 ` Ramkumar Ramachandra
2013-08-08 19:37 ` Junio C Hamano
2013-08-08 20:04 ` Ramkumar Ramachandra
2013-08-08 21:09 ` Martin Langhoff
2013-08-09 11:00 ` Jeff King [this message]
2013-08-09 13:34 ` Ramkumar Ramachandra
2013-08-09 17:35 ` Junio C Hamano
2013-08-09 22:16 ` Jeff King
2013-08-10 1:24 ` Duy Nguyen
2013-08-10 9:50 ` Jeff King
2013-08-10 5:26 ` Junio C Hamano
2013-08-10 8:42 ` Ramkumar Ramachandra
2013-08-10 9:24 ` Duy Nguyen
2013-08-10 9:28 ` Duy Nguyen
2013-08-10 9:43 ` Jeff King
2013-08-10 9:50 ` Duy Nguyen
2013-08-10 10:05 ` Ramkumar Ramachandra
2013-08-10 10:16 ` Duy Nguyen
2013-08-10 9:38 ` Jeff King
2013-08-07 0:10 ` Martin Fick
2013-08-08 2:18 ` Duy Nguyen
2013-08-07 0:25 ` Martin Fick
2013-08-07 4:36 ` Ramkumar Ramachandra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130809110000.GD18878@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mfick@codeaurora.org \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.