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

[Nick Edelen <sirnot@gmail.com>]

I can see the logic behind Johannes's ideas, but I'm still not sure
it'd be a great modification.  If you wanted to associate revision
caching much more strongly with packs, then packs and slices could be
merged reasonably well.  Say you just attached the actual slice data
at the end of the pack, then stored offsets of the slice payload in
the pack index.  Since you'd (presumably) have to search the index for
the object anyway, you wouldn't have to deal with searching a
rev-cache index on top of that (although it's not exactly unoptimized
now).

However, that would sorta be preemptively limiting rev-cache to
pack-related optimizations.  I mean at the moment that's the main
target, but it could be improved in the future to be more relavant to
other operations as well.  Leaving the rev-cache as a seperate system
would keep both it and packing much more flexible, and open to
longer-term developments.

>I haven't read the side of the patch that _uses_ the information stored in
>the rev-cache to figure out what it optimizes and what its limitations are
>(e.g. how it interacts with pathspecs).  Perhaps the rev-cache may turn
>out to be _only_ useful for pack-objects and nothing else, in which case
>we may not care about standalone version of rev-cache generator after all.

rev-cache's cache slice traversal basically emulates git's revision
walker, on a smaller scale.  At the moment it only really handles date
limiting (and obviously slop stuff) so it's not used for any pruning.
That's not to say it couldn't be updated in the future though.