bzr-explorer performance question

[Maritza Mendez]

On Sun, Jun 27, 2010 at 12:52 PM, John Arbash Meinel <john at arbash-meinel.com
> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> ...
>
> > Step 4A: refresh working pane in bzr-explorer
> >             -- a few seconds (less than 10sec) for Ubuntu
> >             -- 4.5 minutes for Windows (!)
> >
>
> ...
>
> > 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
> >
>
> One thing to check. Do:
>
>  bzr co --lightweight $SOURCE new-workingtree
>  cd new-workingtree
>  time bzr status
>
> And see what the timing is. The specific thing we are looking for is the
> time of the *first* status.
>
> It is *possible* that we aren't getting the timestamp => sha1 cache
> getting written correctly during the checkout. Which is causing us to
> recompute the sha1 sum of your entire tree.
>
> IIRC, the potential issue is because:
>
>  f = open('foo', 'rb')
>  st1 = os.fstat(f)
>  st2 = os.lstat('foo')
>
> On everything but Windows, those give identical results. However on
> Windows, they might differ. And IIRC the way that they differ is
> different for different versions of python. (2.5 used st_dev, 2.6 uses
> st_ino, or something along those lines.)
>
> Anyway, if you are experiencing this:
>
> a) We can fix it by just ignoring those fields, but we need to know what
> to ignore.
>
> b) It should only effect the first status/refresh that you do. All
> others should still be in the 'couple of seconds' range.
>
> John
> =:->
>
>

John,

I was able to repeat this experiment on without the access errors.  (I do
not knwo why I was getting access errors yesterday -- especially logged in
as root -- but that may be unrelated.)

bzr co --lightweight ./trunk ./co
cd co
bzr status  # takes 33.5 seconds
bzr status  # takes 0.8 second
bzr status  # takes 0.8 second

So, yes, it does appear that the first 'bzr stat' after a checkout takes
longer than subsequent runs -- but noweher near the 4.5 minutes that
bzr-explorer took.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100628/64fda9be/attachment.htm