我正在使用驻留在P2（Panasonic）卡上的一些非常大的文件。我们采用的部分过程是首先生成我们要复制的文件的校验和，然后复制文件，然后对文件运行校验和以确认它已复制好。问题是文件很大（70 GB +）并且需要很长时间才能完成。这是一个问题，因为我们最终将处理数以千计的这些文件。
我想找到一种更快的方法来生成校验和，而不是使用System.Security.Cryptography.MD5CryptoServiceProvider 我不在乎这是否意味着使用专用硬件卡，只要它有效且不昂贵。我更喜欢有一种编码方法，它提供了一些关于过程进展的反馈，因此我可以像现在一样显示它。
该应用程序是用vb.net编写的。我希望能够在我的应用程序中将它用作组件，库，引用，但是如果生成校验和的速度有足够的改进，我愿意调用外部应用程序。
毋庸置疑，校验和必须一致且正确。 ： - ）
提前感谢您的时间和精力，
理查德
答案 0 :(得分：2)
我看到了一种加速此过程的潜在方法：计算源文件的MD5 ，而执行复制，而不是之前。这将减少您需要从3（源散列，复制，目标散列）到2（复制，目标散列）读取整个文件的次数。
这一切的缺点是你必须编写自己的复制代码（而不是仅仅依赖于System.IO.File.Copy），并且这将是非零的可能性，结果是最后还是比三步过程慢。
除此之外，我认为你在这里做的事情并不多，因为整个过程都受到设计的I / O限制。您将大部分时间用于读取/写入文件，即使是100MB / s（典型SATA驱动器的I / O速度也相当可观），您最多只能达到5.8GB / min。
使用现代处理器，计算MD5（或其他任何东西）的开销并不会影响很多，因此加快速度并不会提高整体吞吐量。加密加速器特别对此没有帮助，因为除非驱动程序实现非常高效，否则由于将数据提供给外部卡所需的上下文切换而不是保存，它们会增加更多的开销。
您希望改进的是I / O速度。 .NET框架在这方面已经非常高效（使用大小合适的缓冲区，重叠的I / O等），但优化的本机Windows应用程序可能在这里表现更好。我的建议：Google around用于一些本机MD5计算器，并了解它们与您当前的.NET实现的比较。如果哈希计算速度的差异大于10％，则值得切换到使用所述外部应用程序。
答案 1 :(得分：1)
正确答案是避免使用MD5。 MD5是一种加密哈希函数，旨在提供某些加密功能。仅仅为了检测意外腐败，它是过度设计和缓慢的。有许多更快的校验和，通过检查错误检测和校正的文献可以理解其设计。一些常见的例子是CRC校验和，其中CRC32非常常见，但您也可以比MD5哈希相对容易地计算64或128位甚至更大的CRC。