largefiles: overheads to hg startup

[Na'Tosha Bard]

2011/10/24 Victor Suba <vosuba at gmail.com>

> Hi,
>
> 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
> contributing a patch.
>
> I realized that largefiles (and kbfiles) were adding significant time to
> "hg status" and "hg commit".
>

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.

When either of these extensions is enabled they have a cost, perhaps even
> more so if large files are not used in the repository.
>
> 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
>
> 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
> 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.
>

I'll have a look at this; it is probably an easy fix.


> Second portion is the extension calls dirstate.status twice compared to the
> usual once, and does some extra processing that makes up
> the rest of the time.
>

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.

Hit across this because I'm evaluating Mercurial for recommendation at my
> company and large files support is very interesting to me.
> When benchmarking Mercurial 2.0rc or the version of Mercurial in Kiln
> versus Git, I was getting these poor 6.5s timings for Mercurial
> 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
> faster than Git :-) .
>
> Thanks,
> Victor
>

Cheers,
Na'Tosha

-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111024/08c5d3c2/attachment.html>