2011/10/24 Victor Suba <span dir="ltr"><<a href="mailto:vosuba@gmail.com">vosuba@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<div><br></div><div>Sorry for starting with just describing an issue instead of providing a patch.  Still trying to figure out the code fully before I can consider</div><div>contributing a patch.</div><div><br></div><div>

I realized that largefiles (and kbfiles) were adding significant time to "hg status" and "hg commit".</div></blockquote><div><br>I believe this should be helped significantly in "hg commit"  with a previous patch of mine.  Otherwise, yes, it does add additional time, which we need to figure out why and fix it.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>When either of these extensions is enabled they have a cost, perhaps even more so if large files are not used in the repository.</div>

<div><br></div><div>On mozilla-central, "hg status" goes from 0.7s to 6.5s with "largefiles" enabled (on Win 7 with cached file system;  from cold it's much slower)11</div><div><br></div><div>A significant portion (3.5s) is in checkrequireslfiles, which I guess is searching for the existence of '.hglf'.  On a repo that doesn't use</div>

<div>largefiles, this check will always run (hence worse degrade for repos that don't use "largefiles" than those that do).  Speeding up the check here would make a big difference.</div></blockquote><div><br>
I'll have a look at this; it is probably an easy fix.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div></div><div>Second portion is the extension calls dirstate.status twice compared to the usual once, and does some extra processing that makes up</div>

<div>the rest of the time.</div></blockquote><div><br>I suspect that improving this would require a refactoring significant enough to be rejected since we are past the code freeze.  We could look into it and target 2.1, however. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div></div><div>Hit across this because I'm evaluating Mercurial for recommendation at my company and large files support is very interesting to me.</div>
<div>When benchmarking Mercurial 2.0rc or the version of Mercurial in Kiln versus Git, I was getting these poor 6.5s timings for Mercurial</div>
<div>while Git was giving me 0.9s, but when I started profiling the code I realized it was these extensions, and the base Mercurial is running</div><div>faster than Git :-) .</div><div><br></div><div>Thanks,</div><div>Victor</div>
</blockquote><div><br>Cheers,<br>Na'Tosha <br></div></div><br>-- <br><div><div><span style="color: rgb(153, 153, 153);"><b>Na'Tosha Bard</b></span></div><div><font color="#999999">Build & Infrastructure Developer | Unity Technologies</font></div>
<div><font color="#999999"><br></font></div><div><font color="#999999"><b>E-Mail:</b> <a href="mailto:natosha@unity3d.com" target="_blank">natosha@unity3d.com</a></font></div><div><font color="#999999"><b>Skype:</b> natosha.bard</font></div>
</div><br>