compressed weaves, and revision.weave
John A Meinel
john at arbash-meinel.com
Thu Oct 27 04:10:40 BST 2005
Michael Ellerman wrote:
> On Tue, 25 Oct 2005 18:43, John A Meinel wrote:
...
>
> For my kernel tree, only 47 revisions.
>
> 257M working tree
>
> Mainline:
> 5.3M .bzr/inventory.weave
> 380K .bzr/revision-store/
> 283M .bzr
>
> Compressed weaves (compressed):
> 1.1M .bzr/inventory.weave.gz
> 8.0K .bzr/revision.weave.gz
> 117M .bzr
>
> Which is pretty impressive. Although there's not much history, it's pretty
> nice to be storing 47 revisions in 45% the size of the working tree.
That is nice to see.
>
> Having said that, it's a tad on the slow side:
>
> concordia ~/src/work/ckexec$ cbzr --profile st
> 1588655 function calls (1535159 primitive calls) in 18.747 CPU seconds
>
> vs mainline:
>
> concordia ~/src/work/kexec$ bzr --profile st
> 1368395 function calls (1314899 primitive calls) in 11.668 CPU seconds
>
> cheers
>
I'm a little surprised to see it take that much longer. How long is it
if you do "time cbzr st" rather than running --profile.
I've found that --profile seems to be skewed by mutter() calls.
Which should be virtually no-ops if BZR_DEBUG is not set.
Otherwise can you attach the actual profile results. I'm curious why you
would be seeing an extra 200,000 primitive calls. My first guess would
be that it is all the extra time in Weave() for revisions.weave and the
mutter() calls.
But also, if we have compressed weaves like this, it makes it even more
useful to keep the last inventory and revision information in some sort
of cache, rather than hidden in the weaves.
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051026/cf300108/attachment.pgp
More information about the bazaar
mailing list