why `bzr pull bundle` so slow?

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Alexander Belchenko wrote:
> 
>>> Any ideas how to speed it up?
> 
> Nope.  It performs well enough in its intended usage, so I've never
> profiled it.  I'd guess it's due to re-diffing every version of every
> file that is included in the changes, but it's only a guess.
> 
> Aaron

Pull bundle is slow because installing revisions from bundles is slow.

I'm guessing it is because we extract the full texts for everything, and
check their sha1 sums, and regenerate the Testament and check its sha1
sum, etc.

It wouldn't surprise me if we were doing something incorrectly. (Like
extracting the texts of unchanged files, or some other silly mistake).

A few things that would probably help:

1) Improve the speed of extracting a fulltext from a Knit. This is a
bottleneck elsewhere, and we would be doing it a lot during bundle
installation.

2) Profile 'bzr merge bundle' or 'bzr pull bundle', they should have the
same cost.

3) Write a new bundle format that lets us ship around the knit hunks,
rather than having to extract a diff, apply it to a text, and then
re-create the diff when we add it to the Knit file.
http://bazaar-vcs.org/BundleFormat0.10

(note that *creating* the bundle is also very slow).


We also have benchmarks for this.

bzr selftest --benchmark --lsprof-timed \
  few_files_small_tree_100_revision

Might be worth looking at.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOgZAJdeBCYSNAAMRAl0iAJ97aPd39V7Kty7tELGr2HwYSptK2wCgwyId
i8/R8JoKeg24Ll8yVwBAQls=
=1eZK
-----END PGP SIGNATURE-----