slow clone form a windows share

marco gaddoni marco.gaddoni at gmail.com
Tue Apr 10 10:56:26 CDT 2012


On Tue, Apr 10, 2012 at 17:23, Matt Mackall <mpm at selenic.com> wrote:

> On Tue, 2012-04-10 at 09:37 +0200, marco gaddoni wrote:
>
> > local copy, with hardlinks
> >
> > $ hg --time clone -U boost/ boost1
> > Time: real 164.682 secs (user 5.694+0.000 sys 27.378+0.000)
>
> So it took 164 seconds to copy, but a total of 33 seconds of CPU time.
> That's a lot of time spent on I/O, especially for hardlinking. My
> suspicion is that time is being spent scanning for viruses on the newly
> "created" files.
>
> >  $ hg --time clone -U --pull /boost/ boost1
> > requesting all changes
> > adding changesets
> > adding manifests
> > adding file changes
> > added 3 changesets with 37673 changes to 37673 files
> > Time: real 350.398 secs (user 46.738+0.000 sys 40.560+0.000)
>
> 87 seconds of CPU time.
>
> > $ time xcopy /s boost boost3
> > 37715 File copiati
> >
> > real    4m43.539s
>
> 303 seconds of wall time.
>
> > i did some trials inside a virtual machine on the same pc;
>

the vm is a debian stable w ext3 ..


> >
> > time hg clone -U http://192.168.0.20:8000 boost
> > real    0m1.047s
> > user    0m0.015s
> > sys     0m0.031s
>
> This one seems wrong.
>

yes, mt bad. when i did clone a first time
it got created a repository with the default name
192.168.0.20:8000 and a second time it confused
mercurial; the real clone from the net takes
~110 seconds.
strange default name.


>
> > time hg clone -U boost1 boost2
> > real    0m0.082s
> >
> > time hg clone -U --pull boost2 boost3
> > real    0m41.857s
> >
> > in an nfs mount
> > time cp -r /mnt/server/boost boost
> >
> > real 1m0.1
> >
> > i did all these without paying particolar
> > attention to the caching effects of the os.
> >
> > ntfs is surely slower than ext3.
> > maybe it cannot handle as well a lot of
> > small files ?
>
> NTFS performance is pretty bad, but not quite this bad. But virus
> scanners are great for destroying performance.
>
>
no virus scanner enabled.
the tortoisehg status update should be disabled.
a lot of services, but ...

will look a little deeper to the performance of the disk.

thank you for your assistance ...



> > confused :(
> >
> >
> > >
> > >>  > i have tried to clone via web (that is, i run hg serve on
> > >> > the server and cloned on my pc with
> > >> > hg clone http://server:8000/);
> > >> > it died in out of memory ...
> > >> >
> > >> > is this expected ?
> > >>
> > >> Perhaps. Are you running a 32-bit build of Mercurial and trying to
> > >> manipulate files that are hundreds of megabytes when uncompressed?
> > >> Typically, the largest file a 32-bit build of Mercurial on Windows can
> > >> handle is about 400MB. How much physical memory do you have?
> > >>
> > >>
> > > i think i did install the 64 bit tortoise hg.
> > > will check.
> > >
> > >
> >
> > it is the tortoisehg 2.3.0 (x64) installed;
> > can't tell easily if the python inside is a 64bit version.
> >
> >
> > >  --
> > >> Mathematics is the supreme nostalgia of our time.
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > "Reality continues to ruin my life." - Calvin.
> > >
> >
> >
> >
>
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>


-- 
"Reality continues to ruin my life." - Calvin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120410/e6d97bfc/attachment.html>


More information about the Mercurial-devel mailing list