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

Re: [PATCH] git exproll: steps to tackle gc aggression

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Aug 8, 2013, 20:04 UTC
Message-ID
<CALkWK0=nerszb3_YA8P=qXbfAd4Y1rNsHXhfVKzwtj-x80iqkg@mail.gmail.com>
In-Reply-To
<7vwqnw7z47.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
Show 9 quoted lines
>> 3. After a few days of working, the gc heuristics figure out that I
>> have too much garbage and too many packs; a cleanup is required. The
>> gc --auto which doesn't tolerate fragmentation: it tries to put
>> everything into one large pack.
>
> Today's "gc --auto" skims the history shallowly and packs loose
> objects into a single _new_ pack.  If you start from a single pack
> and enough loose objects and run "gc --auto", you will have two
> packs, one intact from the original, one new.

That is when I have lots of loose objects and few packs. We are discussing gc aggression when there are too many packs (how did we get there in the first place if new packs aren't created?): in which case it doesn't tolerate fragmentation, and tries to put everything in one pack. That is both IO and CPU intensive, and we've been trying to tackle that since the start of the thread.

Show 9 quoted lines
> And I see from "(or when ...)" part that you do not know what you
> are talking about.  "push" will not stream existing pack to the
> other end without computation, and it never will.  It will reuse
> existing individual pieces when it can, and having data in a pack
> (even without deltifying, or as a suboptimal delta) is much better
> for push performance than having the same data in a loose object if
> only for this reason, as you do not have to recompress and reencode
> it in a different way (loose objects and undelitifed object in pack
> are encoded differently).

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?

> I've treated this thread as a design discussion, not an education
> session, but the above ended up having more education material than
> anything that would advance the design.

You will need to educate your contributors and potential contributors if you want these problems to be fixed.

Previous: Junio C HamanoNext: Martin Langhoff
Message 13 of 33 in “git exproll: steps to tackle gc aggression”
  1. git exproll: steps to tackle gc aggressionRamkumar Ramachandra, Aug 6, 2013
  2. Duy NguyenAug 6, 2013
  3. Junio C HamanoAug 6, 2013
  4. Ramkumar RamachandraAug 7, 2013
  5. Junio C HamanoAug 8, 2013
  6. Ramkumar RamachandraAug 8, 2013
  7. Junio C HamanoAug 8, 2013
  8. Martin FickAug 8, 2013
  9. Junio C HamanoAug 8, 2013
  10. Ramkumar RamachandraAug 8, 2013
  11. Ramkumar RamachandraAug 8, 2013
  12. Junio C HamanoAug 8, 2013
  13. Ramkumar RamachandraAug 8, 2013
  14. Martin LanghoffAug 8, 2013
  15. Jeff KingAug 9, 2013
  16. Ramkumar RamachandraAug 9, 2013
  17. Junio C HamanoAug 9, 2013
  18. Jeff KingAug 9, 2013
  19. Duy NguyenAug 10, 2013
  20. Jeff KingAug 10, 2013
  21. Junio C HamanoAug 10, 2013
  22. Ramkumar RamachandraAug 10, 2013
  23. Duy NguyenAug 10, 2013
  24. Duy NguyenAug 10, 2013
  25. Jeff KingAug 10, 2013
  26. Duy NguyenAug 10, 2013
  27. Ramkumar RamachandraAug 10, 2013
  28. Duy NguyenAug 10, 2013
  29. Jeff KingAug 10, 2013
  30. Martin FickAug 7, 2013
  31. Duy NguyenAug 8, 2013
  32. Martin FickAug 7, 2013
  33. Ramkumar RamachandraAug 7, 2013

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.