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

Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Aug 7, 2009, 06:08 UTC
Message-ID
<alpine.DEB.1.00.0908070806350.8306@pacific.mpi-cbg.de>
In-Reply-To
<alpine.LFD.2.00.0908070031160.16073@xanadu.home>
Hi,
On Fri, 7 Aug 2009, Nicolas Pitre wrote:
Show 22 quoted lines
> On Fri, 7 Aug 2009, Sam Vilain wrote:
> 
> > Johannes Schindelin wrote:
> > >> the short answer is that cache slices are totally independant of 
> > >> pack files.
> > >>     
> > >
> > > My idea with that was that you already have a SHA-1 map in the pack 
> > > index, and if all you want to be able to accelerate the revision 
> > > walker, you'd probably need something that adds yet another mapping, 
> > > from commit to parents and tree, and from tree to sub-tree and blob 
> > > (so you can avoid unpacking commit and tree objects).
> > >   
> > 
> > Tying indexes together like that is not a good idea in the database 
> > world. Especially as in this case as Nick mentions, the domain is 
> > subtly different (ie pack vs dag). Unfortunately you just can't try to 
> > pretend that they will always be the same; you can't force a full 
> > repack on every ref change!
> 
> Right.  And the rev cache must work even if the repository is not 
> packed.

Umm, why? AFAICT the principal purpose of the rev cache is to help work loads on, say, www.kernel.org.

I am unlikely to notice the improvements in my regular "git log" calls that only show a couple of pages before I quit the pager.

Ciao, Dscho

Previous: Nicolas PitreNext: Nicolas Pitre
Message 17 of 34 in “Suggested for PU: revision caching system to significantly speed up packing/walking”
  1. 0/5 Suggested for PU: revision caching system to significantly speed up packing/walkingNick Edelen, Aug 6, 2009
  2. Johannes SchindelinAug 6, 2009
  3. Michael J GruberAug 6, 2009
  4. Nick EdelenAug 6, 2009
  5. Johannes SchindelinAug 6, 2009
  6. Nick EdelenAug 6, 2009
  7. Nick EdelenAug 6, 2009
  8. Shawn O. PearceAug 6, 2009
  9. A Large Angry SCMAug 6, 2009
  10. Shawn O. PearceAug 6, 2009
  11. A Large Angry SCMAug 6, 2009
  12. Nick EdelenAug 7, 2009
  13. Johannes SchindelinAug 7, 2009
  14. Nicolas PitreAug 7, 2009
  15. Sam VilainAug 7, 2009
  16. Nicolas PitreAug 7, 2009
  17. Johannes SchindelinAug 7, 2009
  18. Nicolas PitreAug 7, 2009
  19. Johannes SchindelinAug 8, 2009
  20. Junio C HamanoAug 8, 2009
  21. Sam VilainAug 8, 2009
  22. Nicolas PitreAug 9, 2009
  23. Nick EdelenAug 9, 2009
  24. Johannes SchindelinAug 7, 2009
  25. Nicolas PitreAug 7, 2009
  26. Nick EdelenAug 7, 2009
  27. Junio C HamanoAug 7, 2009
  28. Nick EdelenAug 7, 2009
  29. Junio C HamanoAug 8, 2009
  30. Nick EdelenAug 8, 2009
  31. Jeff KingAug 8, 2009
  32. Nick EdelenAug 8, 2009
  33. Jeff KingAug 8, 2009
  34. Junio C HamanoAug 8, 2009

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.