RFC: caching in CHKInventory

[Andrew Bennetts]

Robert Collins wrote:
> I'm building up a CHKInventory class, which is a demand-loadable
> inventory representing a serialised inventory only. (So its not used, or
> intended to be used during e.g. commit).
> 
> I'm wondering whether to cache, or not. The CHKMap class will cache
> (because writing nodes out before all changes are made is expensive, and
> we need a way to make-and-update the maps, and our experience with BTree
> suggests a small cache is really needed). The CHKMap is currently
> mutable to allow creation, but I may make it immutable and create it by
> 'update-from-empty' using the 'apply delta' operation. There will be 1
> or 2 maps per CHKInventory. (path->id, id->path, are the two maps, but
> only one is needed to be 'functional' - and I'm at 'make it work').
> 
> The apply-delta operation at the inventory level will generate a new
> CHKInventory rather than mutating the existing one; which is why I am
> pondering caching at all at this level: accessing individual entries is
> done by a lookup into a CHKMap, and then a parse operation.
> 
> Any strong opinions?

I'm not sure I have enough context to form an opinion.  So instead I'll
ask some questions.

So the underlying CHKMaps cache already...  are these shared at all
between CHKInventories?  Will implementing caching in CHKInventory mean
there are two layers caching the same data?  What exactly are you
considering caching, inventory entry objects?

-Andrew.