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

Hi,

On Fri, 7 Aug 2009, Sam Vilain wrote:

Johannes Schindelin wrote:

quoted

quoted

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.

This is not the same index as in the database world.  It is more 
comparable with a cached view.  And there, it is generally a good idea to 
keep related things in the same cached view (with an outer join), rather 
than having two primary keys for almost every record.

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!

No, but you do not need that, either.  In the setting that is most likely 
the most thankful one, i.e. a git:// server, you _want_ to keep the 
repository "as packed as possible", otherwise the rev cache improvements 
will be lost in the bad packing performance anyway.

quoted

Still, there is some redundancy between the pack index and your cache, 
as you have to write out the whole list of SHA-1s all over again.  I 
guess it is time to look at the code instead of asking stupid 
questions.
  

"Disk is cheap" :-)

Disk I/O ain't.

(Size of the I/O caches, yaddayadda, I'm sure you get my point).

Ciao,
Dscho