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