bzr on Emacs performance suggestions [was: Usage discussion ...]

[Stephen J. Turnbull]

Jason Earl writes:
 > Óscar Fuentes <ofv at wanadoo.es> writes:
 > 
 > > Perfomance sucks.

Yada yada yada.  But I've got bad news, worse news, and a couple
suggestions for you.

The bad news is reported elsewhere: performance is visibly poor
compared to git.

The worse news: git's standard infrastructure is in place even though
it's at best going to be a mirror.  bzr offers only basic html and
sftp access, and for the version savannah-hackers clearly intends to
use whatever is in Debian stable.  Currently that's Bzr 1.17, I think.
This probably doesn't matter for dumb transports, but haven't
improvements been made in the smart protocol on the server side, too?
Ie, it's not clear that it will improve before the repo goes "live".

I don't think there's much you can do about it but brace yourselves
for when the bzr repo goes live.  Stefan's doing what he can to sooth
people, so maybe it will be OK though.

Tiny cheap suggestions: (1) If the progress bar is not going to move
during the download, just replace it with a simple spinner: (/).
(2) Have the rate be the average rate, not the instantaneous rate.
Average is much more informative.  The spinner tells you bytes are
moving, there's no need to get that info from the rate.

In the bzr over http test, the download was clearly either stalling,
or for long periods (in CPU cycles) in the background from the point
of view of the rate measurement, because it would drop to near 0 about
once a second, then bounce back up.  I can only speculate about cause
if it was really stalling; maybe the httpd is heavily loaded compared
to the git server?