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

Re: [PATCH/RFC 0/6] commit caching

From
Duy Nguyen <pclouds@gmail.com>
Date
Jan 30, 2013, 03:31 UTC
Message-ID
<CACsJy8BE3LdxbZzdQXuvEJop23KnnLbCTgPos9CywKV7EY2q9g@mail.gmail.com>
In-Reply-To
<20130129091434.GA6975@sigill.intra.peff.net>
On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> wrote:
Show 7 quoted lines
> The timings from this one are roughly similar to what I posted earlier.
> Unlike the earlier version, this one keeps the data for a single commit
> together for better cache locality (though I don't think it made a big
> difference in my tests, since my cold-cache timing test ends up touching
> every commit anyway).  The short of it is that for an extra 31M of disk
> space (~4%), I get a warm-cache speedup for "git rev-list --all" of
> ~4.2s to ~0.66s.

Some data point on caching 1-parent vs 2-parent commits on webkit repo, 26k commits. With your changes (caching 2-parent commits), the .commits file takes 2241600 bytes. "rev-list --all --quiet":

0.06user 0.00system 0:00.08elapsed 95%CPU (0avgtext+0avgdata 26288maxresident)k 0inputs+0outputs (0major+2094minor)pagefaults 0swaps

With caching 1-parent commits only, the .commits file takes 1707900 bytes (30% less), the same rev-list command:

0.07user 0.00system 0:00.07elapsed 96%CPU (0avgtext+0avgdata 24144maxresident)k 0inputs+0outputs (0major+1960minor)pagefaults 0swaps

Compared to the timing without caching at all:

0.72user 0.02system 0:00.76elapsed 98%CPU (0avgtext+0avgdata 108976maxresident)k 0inputs+0outputs (0major+7272minor)pagefaults 0swaps

The performance loss in 1-parent case is not significant while disk saving is (although it'll be less impressive after you do Shawn's suggestion not storing SHA-1 directly)

-- 
Duy
Previous: Jeff KingNext: Jeff King
Message 38 of 43 in “commit caching”
  1. 0/6 commit cachingJeff King, Jan 29, 2013
  2. 1/6 csum-file: make sha1write const-correctJeff King, Jan 29, 2013
  3. 2/6 strbuf: add string-chomping functionsJeff King, Jan 29, 2013
  4. Michael HaggertyJan 29, 2013
  5. Jeff KingJan 29, 2013
  6. Michael HaggertyJan 30, 2013
  7. 3/6 introduce pack metadata cache filesJeff King, Jan 29, 2013
  8. Junio C HamanoJan 29, 2013
  9. Jeff KingJan 30, 2013
  10. Duy NguyenJan 30, 2013
  11. Jeff KingJan 30, 2013
  12. 4/6 introduce a commit metapackJeff King, Jan 29, 2013
  13. Michael HaggertyJan 29, 2013
  14. Jeff KingJan 29, 2013
  15. Junio C HamanoJan 29, 2013
  16. Junio C HamanoJan 29, 2013
  17. Jeff KingJan 30, 2013
  18. Junio C HamanoJan 30, 2013
  19. Jeff KingFeb 1, 2013
  20. Junio C HamanoJan 30, 2013
  21. Shawn PearceJan 31, 2013
  22. Jeff KingFeb 1, 2013
  23. Junio C HamanoFeb 2, 2013
  24. Jeff KingJan 30, 2013
  25. Duy NguyenJan 30, 2013
  26. Jeff KingJan 30, 2013
  27. Duy NguyenJan 30, 2013
  28. Duy NguyenJan 30, 2013
  29. Duy NguyenJan 31, 2013
  30. Jeff KingFeb 1, 2013
  31. Duy NguyenFeb 2, 2013
  32. Jeff KingFeb 1, 2013
  33. Duy NguyenMar 17, 2013
  34. Jeff KingMar 18, 2013
  35. Jeff KingFeb 1, 2013
  36. 5/6 add git-metapack commandJeff King, Jan 29, 2013
  37. 6/6 commit: look up commit info in metapackJeff King, Jan 29, 2013
  38. Duy NguyenJan 30, 2013
  39. Jeff KingJan 30, 2013
  40. Duy NguyenJan 30, 2013
  41. Shawn PearceJan 31, 2013
  42. Jeff KingFeb 1, 2013
  43. Shawn PearceFeb 2, 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.