incremental pull transfers too much

[Robert Collins]

I did a pull of bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ with local revno 10721, up to revno 10876.

log shows:
748.335 Transferred: 15944KiB (21.3K/s r:11110K w:4834K)

so we read 11M to write 5M to disk. I'm not sure where the overhead is - pack groups (none shown in the log), smart server message info, etc.

[Robert Collins (lifeless)]

Marking as critical because I believe we're getting a reputation as 'slow' again, and this is contributing to it.

[John A Meinel (jameinel)]

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

Robert Collins wrote:
> Public bug reported:
>
> I did a pull of bzr+ssh://bazaar.launchpad.net/~launchpad-
> pqm/launchpad/devel/ with local revno 10721, up to revno 10876.
>
> log shows:
> 748.335 Transferred: 15944KiB (21.3K/s r:11110K w:4834K)
>
> so we read 11M to write 5M to disk. I'm not sure where the overhead is -
> pack groups (none shown in the log), smart server message info, etc.
>

My guess is 'groupcompress' order fetching not being as stable as we
would like (so we take existing groups and fragment them out). Also, we
might have a fair amount of large content already. Stuff that is solo in
a group, that then gets transmitted and recompressed on the client.

I think to minimize this we need both:

1) Server side compression
2) skinny packs

But the former can be done without protocol changes. And may get us a
fair way towards the latter. (Though it does have some CPU cost on the
server side.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvy6awACgkQJdeBCYSNAAMUOACg2gVCkzKV8ob3Cs6SH0t6W7rI
eRYAoI7g6zcLr9Cxu0bQzlQt/8nsQaUd
=J+Ak
-----END PGP SIGNATURE-----