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