From: Nick Edelen Date: Fri, 07 Aug 2009 00:15:17 GMT Subject: Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking Message-ID: In-Reply-To: <4A7B6A94.9020200@gmail.com> 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 wrote: > Shawn O. Pearce wrote: >> >> A Large Angry SCM wrote: >>> >>> Shawn O. Pearce wrote: >>>> >>>> Nick Edelen wrote: >>>>> >>>>> 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. >