parallel copy directory, faster than robocopy

Jay Norwood jayn at prismnet.com
Tue Feb 14 20:27:31 PST 2012


On Wednesday, 15 February 2012 at 00:11:32 UTC, Sean Cavanaugh 
wrote:
 > more of an 'FYI/reminder':
>
> At a minimum Robocopy does additional work to preserve the 
> timestamps and attributes of the copies of the files (by 
> default) so it can avoid redundant copies of files in the 
> future.  This is undoubtedly creating some additional overhead.
>
> Its probably also quite a bit worse with /SEC etc to copy 
> permissions.
>
> On the plus side you would have windows scheduling the IO which 
> in theory would be able to minimize seeking to some degree, 
> compared to robocopy's serial copying.

Yeah, Robocopy has a lot of nice options.  Currently the D 
library has copy (srcpath, destpath), which goes directly to the 
OS copy.   If it had something like 
copy(DirectoryEntry,destpath,options), with the options being 
like the Robocopy options, that might be more efficient.

On the ssd seeking is on the order of 0.2msec vs 16msec on my 
7200rpm seagate hard drive.  I do think seeks on a hard drive 
will be a problem with all the small, individual file copies.  So 
is Robocopy bundling these up in some way?

I did find a nice solution in std.file for the argv expansion, 
btw, and posted an example on D.learn.  It uses a version of 
dirEntries that has an extra parameter that is used for expansion 
that is available in std.path.






More information about the Digitalmars-d-announce mailing list