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

That would work, but I sorta like the idea of caching the actual
names.  I'm thinking of having a block of slice-unique, null-seperated
names at the end of each slice (ie. not in the mapping) which is
loaded into memory (it wouldn't be very big).  Then each blob/tree
object would have an variable length index referencing a particular
name.

Using the actual names would give us greater flexbility, and allow
rev-cache to output proper rev-list type output (with the names after
the hashes).

On Fri, Aug 7, 2009 at 1:43 AM, A Large Angry SCM[off-list ref] wrote:

Shawn O. Pearce wrote:

quoted

A Large Angry SCM [off-list ref] wrote:

quoted

Shawn O. Pearce wrote:

quoted

Nick Edelen [off-list ref] wrote:

quoted

Hrmm, I just realized that it dosn't actually cache paths/names...

You may not need the path name, but instead the hash value that
pack-objects computes from the path name.

Please do NOT expose the hash values. The hash used by pack-objects is
 an implementation detail of the heuristics used by the _current_ object
 packing code. It would be a real shame to have to maintain backward
 compatibility with it at some future date after the packing machinery  has
changed.

This is a local cache.  If there was a version number in the header,
and the hash function changes, we could just bump the version number
and invalidate all of the caches.

No sense in storing (and doing IO of) huge duplicate string values
for something where we really only need 32 bits, and where a
recompute from scratch only costs a minute.

That will work for me if the cache gets a version number and iff the
pack-objects hash code gets big warning comments about the cache code
dependency.