简体   繁体   English

FileInfo.move 与 RoboCopy /MOV 速度:效率

[英]FileInfo.move vs RoboCopy /MOV speed:efficiency

This question is partially coming from a curiosity standpoint, but also from a practical one.这个问题部分来自好奇的角度,但也来自实际的角度。

The application I'm building has a need to copy files from a computer to a USB and back.我正在构建的应用程序需要将文件从计算机复制到 USB 并返回。 For this we use robocopy, and don't intend to change that.为此,我们使用 robocopy,并且不打算改变它。

But prior to doing the copy action, we create a backup of the contents.但在执行复制操作之前,我们会创建内容备份。 For example:例如:

  • Backup contents of E:\ into E:\USB_Backup将 E:\ 的内容备份到 E:\USB_Backup
  • Copy from C:\SomeFolder to E:\从 C:\SomeFolder 复制到 E:\

Or或者

  • Backup C:\Destination to C:\Destination\USB_Backup备份 C:\Destination 到 C:\Destination\USB_Backup
  • Copy from E:\ to C:\Destination, ignoring 'USB_Backup' folder.从 E:\ 复制到 C:\Destination,忽略“USB_Backup”文件夹。

The copying of the files will be done with robocopy.文件的复制将使用 robocopy 完成。 But my concern is moving the files to the backup for this question.但我担心的是为这个问题将文件移动到备份中。 Robocopy seems to copy all files, then delete the source. Robocopy 似乎复制了所有文件,然后删除了源。 Meanwhile windows explorer drag and drop is much quicker, because it just updates the paths of the files.同时 windows 资源管理器拖放要快得多,因为它只是更新文件的路径。

In that scenario, where the drive letter stays the same just the folder path is changed, would a loop that uses FileInfo.move() be quicker?在那种情况下,驱动器号保持不变,只是文件夹路径发生了变化,使用 FileInfo.move() 的循环会更快吗?

Alrighty, I finally have some time to perform and report the results of my testing here for anyone in the future who might have a similar question.好的,我终于有时间在这里为将来可能有类似问题的任何人执行和报告我的测试结果。

Doing a loop at the top-level if way faster.如果速度更快,则在顶层执行循环。

USB2.0 drive was used for testing Source: D:\MoveSource USB2.0驱动用于测试来源:D:\MoveSource
Dest: D:\MoveDest目的地:D:\MoveDest
194MB of files -> 2,696 Files, 87 Folders 194MB 文件 -> 2,696 个文件,87 个文件夹

Using RoboSharp to perform the move operation:使用 RoboSharp 执行移动操作:

RoboSharp.RoboCommand rc = new RoboCommand(MoveSource, MoveDest, true);
rc.CopyOptions.MoveFilesAndDirectories = true;
rc.CopyOptions.MultiThreadedCopiesCount = 1;
rc.CopyOptions.CopySubdirectoriesIncludingEmpty = true;
rc.Start().Wait();

//Command: D:\Source D:\Dest "*.*" /COPY:DAT /DCOPY:DA /E /MOVE /MT:1 /R:0 /W:30 /V  /BYTES 
// Results: Directories: 88, Files: 2696, Bytes: 204282757, Speed: 1852148 Bytes/sec

Total elapsed time: 225,215ms (performed 1 run only because I know this operation is several minutes on average in my application using this method, so the result was well within expected)总运行时间:225,215 毫秒(仅执行 1 次运行,因为我知道使用此方法在我的应用程序中此操作平均需要几分钟,因此结果在预期范围内)

Here was my code for a top-level move (one that doesn't dig into folder structure, compare or filter files, or log anything)这是我的顶级移动代码(不深入文件夹结构、比较或过滤文件或记录任何内容的代码)

var dirs = Directory.GetDirectories(MoveSource);
var files = Directory.GetFiles(MoveSource);
string dest;
int i = 0;
long msTotal = 0;
while (i < 20)
{
    var SW = StopWatchStart();
    Directory.CreateDirectory(MoveDest);
    foreach (var d in files)
    {
        dest = Path.Combine(MoveDest, Path.GetFileName(d));
        Directory.Move(d, dest);
    }
    foreach (var d in dirs)
    {
        var D = new DirectoryInfo(d);
        dest = Path.Combine(MoveDest, D.Name);
        D.MoveTo(dest);
    }
    Directory.Delete(MoveSource, true);
    SW.Stop();
    msTotal += SW.ElapsedMilliseconds;
    int tries = 0;
    while (Directory.Exists(MoveDest) && tries < 30)
    {
        try
        {
            tries++;
            Task.Delay(350).Wait();
            Directory.Move(MoveDest, MoveSource);
        }
        catch { }
        }
    i++;
}

Average Time (20-run average): 973ms平均时间(20 次运行平均):973 毫秒

Using a recursive loop to dig into the folder structure in the same manner RoboCopy does (which would then be able to be used for filtering/logging/etc if needed) had a average elapsed time of 38,499ms(20 run average), which is still 5x quicker than RoboCopy performed for the same test (granted I wasn't logging file sizes or generating any results data) ( I ran this test with an average because after 3 runs that were pretty quick compared to RoboCopy, but still had minor swings, I figured this would be a good thing to average).使用递归循环以与 RoboCopy 相同的方式挖掘文件夹结构(如果需要,它可以用于过滤/记录/等)的平均经过时间为 38,499 毫秒(20 次运行平均值),即仍然比 RoboCopy 在同一测试中执行的速度快 5 倍(假设我没有记录文件大小或生成任何结果数据)(我以平均值运行此测试,因为与 RoboCopy 相比,运行 3 次后速度相当快,但仍然有轻微的波动,我认为这将是一件好事)。

So the results are:所以结果是:

  • RoboSharp ( RoboCopy ) -> 225,215ms RoboSharp (RoboCopy) -> 225,215ms
  • Recursive Routine that digs into the structure and uses FileInfo.MoveTo() -> 38,499ms (20 run average)深入研究结构并使用FileInfo.MoveTo() -> 38,499 毫秒(平均 20 次运行)的递归例程
  • Directory.Move() that loops through the top-level folder's directories and files -> 973ms (20 run average)循环遍历顶级文件夹的目录和文件的Directory.Move() -> 973 毫秒(平均 20 次运行)

Now since that was using a USB2.0 device, I'm likely going to re-run this test over a network drive before really implementing it into my application.现在因为使用的是 USB2.0 设备,所以我可能会在将其真正实施到我的应用程序之前通过网络驱动器重新运行此测试。 But manually performing the loop is MUCH faster than robocopy, but you would have to add in all the scenarios robocopy can test for, which would then add in processing time.但是手动执行循环比 robocopy 快得多,但是您必须添加 robocopy 可以测试的所有场景,这会增加处理时间。 Since my application is a simple bulk move for backup purposes, the recursive loop will be much quicker.由于我的应用程序是用于备份目的的简单批量移动,因此递归循环会快得多。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM