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