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

Martin Pool mbp at sourcefrog.net
Tue Nov 20 02:04:54 GMT 2007


On Nov 17, 2007 6:53 PM, Wichmann, Mats D <mats.d.wichmann at intel.com> wrote:

> 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).

I realize they may not be, but if these are public trees we could try
using them for benchmarking of new changes -- though they do seem in
the same range as trees we regularly benchmark on.

> 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.

It would be interesting if you could press C-\ when it's stalled here,
then type 'bt' to get a backtrace indicating just what it's doing.

> 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.

Although satellites have high bandwidth they do have famously high
latency too, just because of the speed of light.  So any extra round
trips really will hurt.

If it is possible for you to change to packs at some point that should
help, since they need to create or update fewer files.

By running eg 'bzr -Dhpss push' you'll get a trace in ~/.bzr.log of
all of the rpcs, including the time they took.  Andrew has some
continuing work to reduce the number of trips this takes.

-- 
Martin



More information about the bazaar mailing list