gpt4 book ai didi

python - 在 python 中为大文件创建校验和的最快方法

转载 作者:太空狗 更新时间:2023-10-29 23:56:20 26 4
gpt4 key购买 nike

我需要通过网络传输大文件,并且需要每小时为它们创建校验和。所以生成校验和的速度对我来说至关重要。

我无法使 zlib.crc32 和 zlib.adler32 在 Windows XP Pro 64 位机器上处理大于 4GB 的文件。我怀疑我在这里达到了 32 位限制?使用 hashlib.md5 我可以获得结果,但问题是速度。为 4.8GB 的​​文件生成 md5 大约需要 5 分钟。任务管理器显示该进程仅使用一个核心。

我的问题是:

  1. 有没有办法让 crc 在大文件上工作?我更喜欢使用 crc 而不是 md5
  2. 如果不是,那么有没有办法加快 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/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com