[MERGE] Remove knit caches
Robert Collins
robertc at robertcollins.net
Tue Jun 27 09:44:25 BST 2006
On Mon, 2006-06-26 at 10:21 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
Thats fine - I was at UDS with 0 spare cycles, so I saw the message go
by but had no time to reply to it.
> > 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.
Conversion of a tree with 8000 inventories has this access pattern:
insert rev 0
insert rev1 reads rev0
insert rev2 reads rev0 rev1
insert rev3 reads rev0 rev1 rev2
...
insert rev51 reads rev50
insert rev52 reads rev50 rev51
...
etc.
The counts from 0 to 50 accumulate up the lines of left-most ancestor
history, so 'cache the last 50 inserts' is not sufficient to get optimal
hit rate, but is better than no caching as such.
> 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.
This might be a reasonable approach.
Cheers,
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060627/96e5ea63/attachment.pgp
More information about the bazaar
mailing list