On Fri, Jul 13, 2012 at 1:19 PM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com" target="_blank">mpm@selenic.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>I don't think we've fully understood the underlying issues here.</div></blockquote><div><br></div><div>It seems you're right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


My working theory has been that we're thrashing the journal.</blockquote><div><br></div><div>That was mine, too.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Under such a theory, I would expect the following three tests to yield<br>
very similar times:<br>
<br>
 cp -a /ramfs/bare-repo /home/repo  (baseline)<br>
 hg clone -U /ramfs/bare-repo /home/repo<br>
 hg serve -R /ramfs/bare-repo; hg clone <a href="http://localhost:8000" target="_blank">http://localhost:8000</a> /home/repo<br>
<br>
For the Mozilla-central repo, the first two come in at about 1m, with cp<br>
being marginally faster. But the hg serve case is coming in at over 2m<br>
without any sign of a CPU bottleneck.<br></blockquote><div><br></div><div>Are you doing a sync afterwards?</div><div><br></div><div>On my machine:</div><div><ul><li>"cp -a" takes 8 seconds</li><li>
"tar | tar" takes about 4.5</li><li>"tar | nc; nc | tar" takes about 5.5 (just making sure that the network stack isn't at fault)</li><li>"hg serve; hg clone --uncompressed -U" takes ... 35 seconds !?</li>
</ul>So that's rather interesting. It prompted me to dig a little deeper.</div><div><br></div><div>First observation: the files streamed are presented in a crazy random order, which surprised me. The culprit: fncache iterating over the elements of a set. <a href="http://selenic.com/repo/hg/file/c6f88e7f95b7/mercurial/store.py">http://selenic.com/repo/hg/file/c6f88e7f95b7/mercurial/store.py</a></div>
<div><br></div><div>Just fixing this improved the performance of uncompressed clone to 25 seconds, which is rather nice for a one-line change. The digging continues.</div></div>