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

Re: git gc --aggressive led to about 40 times slower "git log --raw"

From
Duy Nguyen <pclouds@gmail.com>
Date
Feb 18, 2014, 09:45 UTC
Message-ID
<CACsJy8D9tws_gu6yWVdz3t+Vfg5-9iorptn4BLnTL3b+YWcHzQ@mail.gmail.com>
In-Reply-To
<87r470ssuc.fsf@fencepost.gnu.org>
On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup <dak@gnu.org> wrote:
Show 25 quoted lines
> Christian Jaeger <chrjae@gmail.com> writes:
>
>> I've got a repository where "git log --raw > _somefile" took a few
>> seconds in the past, but after an attempt at merging some commits that
>> were collected in a clone of the same repo that was created about a
>> year ago, I noticed that this command was now taking 3 minutes 7
>> seconds. "git gc", "git fsck", "git clone file:///the/repo/.git" also
>> now each took between ~4-10 minutes, also "git log --raw somefile" got
>> equally unusably slow. With the help of the people on the IRC, I
>> tracked it down to my recent use of "git gc --aggressive" in this
>> repo. Running "git repack -a -d -f" solved it, now it's again taking
>> 4-5 seconds. After running "git gc --aggressive" again for
>> confirmation, "git log --raw > _somefile" was again slowed down,
>> although now 'only' to 1 minute 34 seconds;
>
> [...]
>
>> I've now learned to avoid "git gc --aggressive". Perhaps there are
>> some other conclusions to be drawn, I don't know.
>
> I've seen the same with my ongoing work on git-blame with the current
> Emacs Git mirror.  Aggressive packing reduces the repository size to
> about a quarter, but it blows up the system time (mainly I/O)
> significantly, quite reducing the total benefits of my algorithmic
> improvements there.

Likely because --aggressive passes --depth=250 to pack-objects. Long delta chains could reduce pack size and increase I/O as well as zlib processing signficantly. Christian can try "git repack -adf" which is really close to --aggressive (except it uses default --depth=50) and see if it makes any difference.

Show 17 quoted lines
> There is also some quite visible additional time spent in zlib, so a
> wild guess would be that zlib is not really suited to the massive amount
> of directory entries of a Git object store.  Since the system time still
> dominates, this guess would only make sense if Git over zlib kept
> rereading the directory section of whatever compressed file we are
> talking about.  But that's really a rather handwavy wild guess without
> anything better than a hunch to back it up.  I don't even know what kind
> of compression and/or packs are used: I've only ever messed myself with
> the delta coding of the normal "unpacked" operation (there are a few
> older commits from me on that).
>
> --
> David Kastrup
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Duy
Previous: David KastrupNext: David Kastrup
Message 3 of 31 in “git gc --aggressive led to about 40 times slower "git log --raw"”
  1. Christian JaegerFeb 18, 2014
  2. David KastrupFeb 18, 2014
  3. Duy NguyenFeb 18, 2014
  4. David KastrupFeb 18, 2014
  5. Jonathan NiederFeb 18, 2014
  6. Junio C HamanoFeb 18, 2014
  7. Duy NguyenFeb 18, 2014
  8. Junio C HamanoFeb 19, 2014
  9. Duy NguyenFeb 19, 2014
  10. Philippe VaucherFeb 19, 2014
  11. David KastrupFeb 19, 2014
  12. Duy NguyenFeb 19, 2014
  13. Duy NguyenFeb 19, 2014
  14. Christian JaegerFeb 20, 2014
  15. David KastrupFeb 20, 2014
  16. David KastrupFeb 20, 2014
  17. David KastrupFeb 20, 2014
  18. Junio C HamanoFeb 19, 2014
  19. Duy NguyenFeb 20, 2014
  20. Christian JaegerFeb 21, 2014
  21. Junio C HamanoFeb 21, 2014
  22. Duy NguyenFeb 21, 2014
  23. Junio C HamanoFeb 21, 2014
  24. Philippe VaucherFeb 24, 2014
  25. Duy NguyenFeb 22, 2014
  26. David KastrupFeb 22, 2014
  27. David KastrupFeb 22, 2014
  28. Duy NguyenFeb 22, 2014
  29. Duy NguyenFeb 22, 2014
  30. Andreas SchwabFeb 22, 2014
  31. Christian JaegerFeb 18, 2014

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.