[MERGE] Remove knit caches

Aaron Bentley aaron.bentley at utoronto.ca
Mon Jun 26 15:21:12 BST 2006

Hash: SHA1

Robert Collins wrote:
> On Sun, 2006-06-25 at 19:21 -0400, Aaron Bentley wrote:

>>Therefore, I propose that we get rid of the knit caches.  It seems to be
>>best to do them at a higher level, instead.
> I put them in for conversions from weaves - multiple inserts of non-knit
> data.

Oh, okay.  I did try to have some discussion before doing this, but no
one realized that this was what they were intended to accelerate.

> The win there was to take some operations from hours down to minutes,
> particularly for inventory insertions.
> I'm happy for them to be taken out, as I was never particularly happy
> about them being in, but the conversion path should be kept fast.

As a general API, the cache behaved badly when KnitVersionedFiles were
used in the obvious way.  I'm not sure what level you're using knits at.
 If you're able to predict all the texts/records you'll need, then we
probably don't need to change the API.

If your use case does require this caching functionality, I think it
would be best to make it something explicitly requested, to avoid
gotchas in the  general case.  Perhaps this could be accomplished by
subclassing _KnitData.

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list