hg archive (files) performance regression.

[Vincent Parrett]

On 2/03/2018 4:31 PM, Vincent Parrett wrote:
> I'm not a python dev (mostly c# and delphi), so still getting my head 
> around the hg code base, but I'm curious why the atomictemp=true is 
> used in fileit.addfile? I get that it's in the vfs to work around file 
> locking issues, but with the archive command with type files, it's 
> likely that the archive is going to an empty target directory and this 
> seems wasteful. 

So I just knocked up an extension (ciarchive) using the code from 
archival.py (hg-stable repo) - and in class fileit.addfile :

changed

     f = self.opener(name, "w", atomictemp=True)

to

     f = self.opener(name, "w", atomictemp=False)

hg.exe archive --time --subrepos --no-decode --quiet c:\temp\archive27
time: real 22.224 secs (user 6.203+0.000 sys 12.078+0.000)

hg.exe ciarchive --time --subrepos --no-decode --quiet c:\temp\archive28
time: real 17.316 secs (user 6.609+0.000 sys 7.453+0.000)

The repo has the following files :
             9438 File(s)    531,462,248 bytes
             2039 Dir(s)

That's a substantial performance increase (our customers have very large 
repos where this will make a large difference in build times).  Of 
course I'd much rather not be maintaining an extension that uses the 
internal api of hg, any chance this change can be made in the archive 
command, or at least be made configurable (assuming this change is safe!)?

-- 
Regards

Vincent Parrett

CEO - VSoft Technologies Pty Ltd
https://www.finalbuilder.com
Blog: https://www.finalbuilder.com/resources/blogs
Automate your Software builds with FinalBuilder.
Open Source : https://github.com/VSoftTechnologies