我需要通过网络传输大文件，并且需要每小时为它们创建校验和。所以生成校验和的速度对我来说至关重要。
我无法使 zlib.crc32 和 zlib.adler32 在 Windows XP Pro 64 位机器上处理大于 4GB 的文件。我怀疑我在这里达到了 32 位限制？使用 hashlib.md5 我可以获得结果，但问题是速度。为 4.8GB 的文件生成 md5 大约需要 5 分钟。任务管理器显示该进程仅使用一个核心。
我的问题是:
- 有没有办法让 crc 在大文件上工作？我更喜欢使用 crc 而不是 md5
- 如果不是，那么有没有办法加快 md5.hexdigest()/md5.digest 的速度？或者在这种情况下是任何 hashlib hexdigest/digest？也许将其拆分为多线程进程？我该怎么做？
PS:我正在研究类似于“ Assets 管理”系统的东西，有点像 svn，但 Assets 由大型压缩图像文件组成。这些文件有微小的增量变化。检测更改和错误检测需要哈希/校验和。
最佳答案
这是算法选择问题，而不是库/语言选择问题!
似乎主要考虑两点:
- 磁盘 I/O 对整体性能的影响有多大？
- 错误检测功能的预期可靠性是什么？
显然，第二个问题的答案类似于“允许某些假阴性”，因为相对于 4Gb 消息，任何 32 位散列的可靠性，甚至在中度嘈杂的 channel 中，实际上并不是绝对的。
假设可以通过多线程改进 I/O，我们可以选择不需要顺序扫描完整消息的哈希。相反，我们也许可以并行处理文件，对各个部分进行散列处理，然后组合散列值或附加它们，以形成更长、更可靠的错误检测设备。
下一步可能是将这种文件处理形式化为有序的部分，并按原样传输它们(在收件人端重新粘合在一起)。这种方法，连同有关文件生成方式的附加信息(例如，它们可能会像日志文件一样被追加专门修改)，甚至可能允许限制所需的哈希计算量。这种方法增加的复杂性需要权衡快速 CRC 计算的愿望。
旁注:Alder32 不限于低于特定阈值的消息大小。它可能只是 zlib API 的限制。 (顺便说一句，我找到的关于 zlib.adler32 的引用文献使用了一个缓冲区，而且......在我们的大量消息的上下文中要避免这种方法，有利于流式处理:从文件中读取一点，计算，重复。 .)
关于python - 在 python 中为大文件创建校验和的最快方法，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1532720/