Performance: it's not getting better (for me anyway)

Wichmann, Mats D mats.d.wichmann at intel.com
Sat Nov 17 07:53:13 GMT 2007


I don't have any benchmarks but subjectively it feels 
like bazaar is getting slower, rather than faster.  
With 0.91 and 0.92, even rather simple commits - five 
or less files changed, text diff < 2k bytes - feel 
like they're taking much longer than they used to on 
branches which have a significant history. I've fiddled
a little and simple test branches with a few files 
commit simple changesets much faster so I'm supsicious
that it's either the history or a moderately large 
number of files in the branch which is the factor here.
The two trees which I do the most work in and are
giving me the most grief look like:
(1) 13500 files in branch including metadata, 4400
in working tree, about 2000 revisions
(2) 22000 files in branch including metadata, 5800
in working tree, about 1500 revisions
(these are imported trees with history that dates back
to 2000).

Just watching the progress bars, it seems to figure out 
the affected files quickly, then get to a message where 
it's processing some directory and idle here for long
times, somtimes 30-60 seconds.  This is just really 
irritating.

Another issue, this at least I have some sort of number 
on. I'm suspicious that despite work on reducing the number 
of round-trips, this isn't really getting better either. 
We have "official" trees so my workflow involves making 
local changes then building a merge directive (against a
local mirror branch, to save on bandwidth issues), and 
sending it up to our instance of PQM for merging (PQM is
my worst enemy in a long time but that's another issue). 
Once that's merged, I have to pull on my mirror branch so 
when I get ready to build my next merge directive, I'm 
doing it against an up to date mirror.  Today I was
pulling a large-ish changeset - on the order of 2 meg of 
text diffs.  My connection is a satellite, which is 
reasonably performant on pure downloads (150-200k is not 
uncommon as long as the remote end is behaving) and not
too terrible on uploads - 40-50k or so - but has a severe 
penalty for round-trips.  My pull (using supposed smart
server protocol) took a little over 30 minutes.  I got
a colleague to do an identical pull on his cablemodem 
connection, and it took about two minutes.

I continue to have cases where I can't get a merge done
from what I have, and can't push to a private branch on
our server (for later merging via pqm) because it just
sits for an hour with little apparent progress.  So
instead I rsync my local branch to my remote private
branch in a couple of minutes (<5).  Something is just
really askew with this... "smart" isn't smart if it's
much dumber than rsync; rsync really isn't the ideal way
to do this work although it should be safe on things
which are mine only and have no other users.

If it matters, our branches are all still knit format, 
we have users that we can't force forward quite yet; but
last week I tried converting one branch (locally and 
upstream) that nobody else uses to dirstate-tags and it 
didn't get better in any way that I noticed.



More information about the bazaar mailing list