git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: gc --aggressive

From
Jeff King <peff@peff.net>
Date
Apr 28, 2012, 12:25 UTC
Message-ID
<20120428122533.GA12098@sigill.intra.peff.net>
In-Reply-To
<vpqbomqqdxo.fsf@bauges.imag.fr>
On Tue, Apr 17, 2012 at 10:52:03PM +0200, Matthieu Moy wrote:
Show 16 quoted lines
> Jay Soffian <jaysoffian@gmail.com> writes:
> 
> > + 3. `git gc --aggressive`; this is often much slower than (2) because git
> > +    throws out all of the existing deltas and recomputes them from
> > +    scratch. It uses a higher window parameter meaning it will spend
> > +    more time computing, and it may end up with a smaller pack. However,
> > +    unless the repository is known to have initially been poorly packed,
> > +    this option is not needed and will just cause git to perform
> > +    extra work.
> 
> I like your patch.
> 
> Maybe you should elaborate on "unless the repository is known to have
> initially been poorly packed". My understanding is that --aggressive was
> implemented to be called after an import from another VCS that would
> have computed very poor deltas, but I'm not sure about the details.

Coincidentally, I came across a case last week that shows --aggressive providing a large improvement. And it's a public repo, so I was able to grab a snapshot of the pre-packed state to experiment on and share.

The current packfile is ~246M. It was produced over time by pushes into the repository, which were then eventually grouped into a single pack by "git gc" (I'm not sure of the exact history, but this may even have been a set of "gc --auto" calls over time).

Here's a list of commands and the pack sizes they yield on the repo:
  1. `git repack -ad`: 246M
  2. `git repack -ad -f`: 376M
  3. `git repack -ad --window=250`: 246M
  4. `git repack -ad -f --window=250`: 145M

The most interesting thing is (4): repacking with a larger window size yields a 100M (40%) space improvement. The other commands show that it is not that the current pack is simply bad; command (2) repacks from scratch and actually ends up with a worse pack. So the increased window size really is important.

I haven't been able to figure out what it is about this dataset that makes the bigger window so much better. Certainly doing the same commands on git.git does not yield as impressive a speedup.

If anybody is interested in the repository as a packing test case, you can download it from:

  https://gist.github.com/raw/2518074/d9c0244bf0ced690fee1edb2c88c522ecce102e4/phpmyadmin-network.tar
-Peff
Previous: Jeff KingNext: Nicolas Pitre
Message 5 of 26 in “gc --aggressive”
  1. Jay SoffianApr 17, 2012
  2. Jay SoffianApr 17, 2012
  3. Matthieu MoyApr 17, 2012
  4. Jeff KingApr 17, 2012
  5. Jeff KingApr 28, 2012
  6. Nicolas PitreApr 28, 2012
  7. Jeff KingApr 29, 2012
  8. Nicolas PitreApr 29, 2012
  9. Jeff KingMay 1, 2012
  10. Jeff KingMay 1, 2012
  11. Nicolas PitreMay 1, 2012
  12. Junio C HamanoMay 1, 2012
  13. Nicolas PitreMay 1, 2012
  14. Jeff KingMay 1, 2012
  15. Jeff KingMay 1, 2012
  16. Nicolas PitreMay 1, 2012
  17. Nicolas PitreMay 1, 2012
  18. Jeff KingMay 1, 2012
  19. Nicolas PitreMay 1, 2012
  20. Nicolas PitreApr 28, 2012
  21. Jeff KingApr 17, 2012
  22. Junio C HamanoApr 17, 2012
  23. Jeff KingApr 17, 2012
  24. Junio C HamanoApr 17, 2012
  25. Nicolas PitreApr 28, 2012
  26. Andreas EricssonApr 18, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.