Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
- From
- Nick Edelen <sirnot@gmail.com>
- Date
- Aug 7, 2009, 00:15 UTC
- Message-ID
- <c77435a80908061715u7ff7456cl6c5ded16b51b122f@mail.gmail.com>
- 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<gitzilla@gmail.com> wrote:
Show 32 quoted lines
> Shawn O. Pearce wrote: >> >> A Large Angry SCM <gitzilla@gmail.com> wrote: >>> >>> Shawn O. Pearce wrote: >>>> >>>> Nick Edelen <sirnot@gmail.com> 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. >