我正在开发一个小型实用程序来连接大型视频文件。主要的连接步骤是在 Windows 7 的命令行上运行类似这样的操作:
copy /b file1.dv + file2.dv + file3.dv output.dv
输入文件很大 - 每个通常 7-15GB。我知道我在这里处理了大量的数据,但是二进制连接需要很长时间——总共大约 40GB 的数据,它可以接近一个小时。
考虑到这个过程基本上只是扫描每个文件并将其内容复制到一个新文件,为什么二进制复制这么慢?
我正在开发一个小型实用程序来连接大型视频文件。主要的连接步骤是在 Windows 7 的命令行上运行类似这样的操作:
copy /b file1.dv + file2.dv + file3.dv output.dv
输入文件很大 - 每个通常 7-15GB。我知道我在这里处理了大量的数据,但是二进制连接需要很长时间——总共大约 40GB 的数据,它可以接近一个小时。
考虑到这个过程基本上只是扫描每个文件并将其内容复制到一个新文件,为什么二进制复制这么慢?
内置命令copy
是在 DOS 时代设计的,从那以后就没有真正更新过。因此,它是为具有小磁盘和非常小的主存储器的机器设计的。结果,它在复制东西时使用非常小的缓冲区。对于典型的工作负载;这没什么大不了的,但对于您正在处理的特定情况来说效果不佳。
也就是说,考虑到您描述的情况,我认为复制不会那么缓慢。如果一个 40 GB 的文件需要大约一个小时,这意味着您将获得大约11 MB/s 的速度. 像您在评论中描述的典型商品戴尔笔记本电脑通常配备 5400 RPM 消费级硬盘,在理想的顺序读取和写道。但是,您的工作负载不是顺序工作负载;这是读/写头从源文件到目标文件的不断移动。为此类磁盘加上 16 毫秒的典型延迟,每秒大约有 60 次寻道,或每秒 30 次复制操作。这意味着副本使用了大约 11MB / 30 = 大约 375k 的缓冲区,这很方便(在您考虑了copy
的代码和一些 DOS 设备驱动程序)适合复制最初设计的 640k 上限。这一切都假设您的磁盘在理想条件下运行,并且有足够的剩余空间允许这些读取和写入在复制操作中实际上是连续的。
当然,如果你同时做其他事情,这会导致更多的搜索操作,你的性能会更差。
如果您使用另一个专为大型复制操作而设计的应用程序,并且因此使用更大的缓冲区,您可能会获得更好的结果(可能快两倍)。我不知道有任何这样的应用程序;如果你需要的话,你可能需要自己写一个。