代码之家 › 专栏 › 技术社区 › schmoopy

有没有比复制文件更快的方法。复制

schmoopy · 技术社区 · 16 年前

做一个测试大约需要2分钟 File.Copy(src, dest); 对于同一驱动器上从文件夹a到文件夹B的1.6GB文件。在C#/中有没有更快的方法来实现这一点。NET中的代码(没有硬件)-流、线程等?

文件流会更快吗?一个类如何使用线程池将文件分块,并读取一定范围的字节/写入一定范围的字节[这听起来像是破坏文件的好方法,但完整性并不是这里的首要问题,它的速度:-)]

我已经搜索过了,但每个人都说使用文件。复制,但速度很慢(和Windows Copy一样慢)——我不想使用第三方工具。

以下是一些问题的答案:

复制时间比较:

> C# : 2.15m  
> Windows Explorer: 2.53m  
> TeraCopy: 2.26m
> FastCopy: 2.24m

好的,这些不是平均值,我知道它们可能会在后续运行中发生轻微变化,但我真的认为复制文件的速度会更快,因为我假设Windows正在进行额外的安全性和完整性检查:-(

我仍然希望得到一些好的答案(比如‘哦,是的,超过1.5GB的文件将被删除。’ 十、如果使用缓冲区,速度会更快 M 关掉保安 N “)--好的,我现在只是希望。

8 回复 | 直到 16 年前

Brian Gideon 16 年前

如果您对创建符号链接或硬链接而不是 真实的 复制以下Windows API可能会有所帮助。

Guffa 16 年前

你可以尝试使用你已经掌握的硬件,并在内存中分配一个大的缓冲区。通过大量阅读和写作,你或许可以减少一些开销。

然而,没有太多开销需要消除,瓶颈仍然是磁盘I/O。我最多只能期望执行时间减少5%。

dtb 16 年前

文件抄送打电话给 CreateFile 在内核32中。dll。如果你正在复制大量的小文件(想想数百万),那么做P/Invoke来处理参数和跳过权限要求可能是值得的。一个大文件99.999%的2分钟都花在了驱动程序代码中。

rerun 16 年前

我假设windows复制,文件。copy、Copyfile都使用相同的底层操作系统调用来进行复制。我怀疑你写的任何东西都会胜过操作系统内部调用。

Mark Ransom 16 年前

我还没试过,但可能很快。

执行两个内存映射,一个映射到输入文件,一个映射到输出,并将内存从一个映射到另一个。操作系统执行的页面映射被调整为尽可能高的性能,因为它会影响整个系统的速度。

STW 16 年前

对于同一驱动器中的单个文件,您的问题的答案是: 不 .

对于网络传输、移动大量文件和其他更复杂的场景,可能还有改进的余地。

如果您当前的要求是将GBs复制到同一磁盘上的第二个物理(非符号)位置,那么提高性能的最佳机会可能是更快的磁盘。

Zuljin 16 年前

我认为你应该首先检查一下你的磁盘有多少碎片。如果你的文件有很多块,而你没有足够的连续可用空间来存放第二块,那么磁盘必须经常移动磁头,这是非常缓慢的。

也许你的磁盘很简单,又旧又慢,你可以达到它的最高性能。在这种情况下,解决方案很简单,您需要购买新的或更好的两个,然后创建RAID 0。

您还可以检查在复制过程中,其他磁盘是否未使用相同的磁盘,例如防病毒或索引服务。

我没有提出任何软件解决方案,因为我认为没有什么比操作系统提供的功能更快的了。

alpha_one_x86 14 年前

如果文件在缓存中,这一切都取决于操作系统在复制时决定的分配(以同样的方式执行5x以避免它)。

最明显的结果是,如果你重复测试多次。