bzr-explorer performance question

[Maritza Mendez]

I was very surprised by what I am about to describe and would like to know
if this is normal for bzr-explorer.  I would not have believed this if I had
not seen it myself.

I apologize for not having exact timings.  The effect I am seeing is large.

The following steps were performed using bzr-explorer 1.0.1 on Windows XP
SP3 and Ubuntu 10.04 one the same machine.  The machine dual boots and has
two identical (same model) Seagate 500GB drives -- one dedicated to each
OS.  Bzr explorer installed using the standalone 2.1.1 installer from
Windows and the PPA for Ubuntu.   We committed the *exact* same project
files to a branch on the Windows and Ubuntu machines:

Step 1 : create a new project using the recommended default "Feature
Branches" workspace model.
            -- takes trivial time on both Windows and Ubuntu.

Step 2: copy existing project files to the newly created trunk.
             -- This project is "binary heavy" and we are likely to have
more projects like this in the future
             -- about 10 MB of "text" source code and docs
             -- about 40 MB of vendor libs (to be versioned)
             -- about 150 MB of binary database files (to be versioned)
             -- total size: 200MB in 305 directories; maximum directory
depth = 8

Step 3: add all content -- takes about two minutes for both Windows and
Ubuntu -- very reasonable

Step 4A: refresh working pane in bzr-explorer
            -- a few seconds (less than 10sec) for Ubuntu
            -- 4.5 minutes for Windows (!)

Step 4B: on Windows, open a 'DOS' box and run 'bzr stat' -- takes only a
couple seconds

Step 5: commit -- about a minute on both platforms -- great!

Step 6: branch to a "feature branch" -- one minute on Ubuntu, 1.5 minutes on
Windows -- very reasonable

We did this two more times to try to minimize any system load effects.  The
timings changed by no more than 10%

Since the test conditions are anecdotal (but the results are reproducible!)
the only result I am really concerned about is in step 4.  It appears that
refreshing the "status window" takes a very long time on Windows, during
which one core of the CPU is saturated.  But doing a 'bzr stat' on the very
same trunk on Windows is fast.  Could there be something strange about how
bzr-explorer builds the status?  What exactly could 'refresh' be doing which
could take 4.5 minutes?

Thanks.
~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100627/d90fbd69/attachment.htm