<br><br><div class="gmail_quote">On Mon, Jun 28, 2010 at 4:34 PM, Maritza Mendez <span dir="ltr">&lt;<a href="mailto:martitzam@gmail.com">martitzam@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
John, <br><div class="gmail_quote"><div><br>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.)<br>

<br>bzr co --lightweight ./trunk ./co<br>cd co<br>bzr status  # takes 33.5 seconds<br>bzr status  # takes 0.8 second<br>bzr status  # takes 0.8 second<br>
<br>So, yes, it does appear that the first &#39;bzr stat&#39; after a checkout takes longer than subsequent runs -- but noweher near the 4.5 minutes that bzr-explorer took.<br><br></div></div>
</blockquote></div><br>Since the original experiment with bzr-explorer was done on a full-fledged branch, and you asked me to do an experiment on a lightweight checkout, I decided to try the same thing in bzr-explorer.  The command bzr-explorer ran was<br>
<br><span style="color: rgb(0, 0, 255);">Run command: bzr checkout --lightweight {PATH_TO_SHARED_REPO}/trunk {PATH_TO_SHARED_REPO}/co2</span><br><br>which took a couple minutes.  Then it was an extra 32 seconds to update the status window after I pressed &quot;refresh&quot;.  (Note that I have automatic refresh turned off, so that I control when it happens and I can time it.)  Then, pushing Refresh again and again updates in less than a second each time.  This is at least consistent with what we saw on the command-line (previous post).<br>
<br>I understand in principle what you&#39;re speculating about fstat and lstat, although I don&#39;t know the particulars.  What I do know is that be-explorer 1.0.1 uses the python 2.5.4 interpreter.  I&#39;m not saying that&#39;s the problem, of course.<br>
<br>I have one more experiment to do.  I need to start from scratch, following the process I originally reported, but this time using the command line instead of bzr explorer.  If the first bzr stat after a massive bzr add is again much slower than subsequent bzr stat commands, then I think we are on to something which Ineed to log as a bug and hand over to you core devs for serious analysis.  Coming up next.<br>
<br>~M<br><br>