Re: Benchmarks regarding git's gc
- From
David Michael Barr <davidbarr@google.com>
- Date
- Nov 9, 2011, 12:34 UTC
- Message-ID
- <CAFfmPPNeriyNbnag9ekXW6YEVzordKNxUCjw837roub8hn+HGw@mail.gmail.com>
- In-Reply-To
- <20111108215812.GB18529@sigill.intra.peff.net>
On Wed, Nov 9, 2011 at 8:58 AM, Jeff King <peff@peff.net> wrote:
Show 14 quoted lines
> On Tue, Nov 08, 2011 at 10:40:15AM -0600, Brandon Casey wrote: > >> On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras >> <felipe.contreras@gmail.com> wrote: >> > Has anybody seen these? >> > http://draketo.de/proj/hg-vs-git-server/test-results.html#results >> > >> > Seems like a potential area of improvement. >> >> I think this is a case of designing the problem space so that your >> intended winner wins and your intended loser loses. > > Sort of. It is a real problem space, and mercurial does have some > advantage in that area.
[...]
Show 7 quoted lines
> So he may have a point that mercurial might perform better for some > metrics than git in the current state. But I think a lot of that is > because nobody has bothered putting git into this situation and done the > tweaks needed to make it fast. You can argue that git sucks because it > needs tweaking, of course, but if I were picking between the two systems > to implement something like this, I'd consider picking git and doing the > tweaks (of course, I'm far from unbiased).
It is the case that the default behaviour of git gc --auto is far from optimal. I've been playing with ways to achieve both better asymptotic performance and less jitter. One part of that is choosing "good" packing parameters for a given repo. I did this in a partially automated fashion for WebKit but I think the process can be generalised. The other issue is how often you repack ancient history, the potential waste is obvious. To this end I propose a repacking strategy in the spirit of merge-sort: If you can maintain the constraint that the sizes of packs in a repo form a geometric sequence, my napkin says the amortised cost of gc is log(n).
-- David Barr.