pix*_*der 6 python crc32 multithreading md5 hashlib
我需要跨网络传输大文件,需要每小时为它们创建校验和.所以产生校验和的速度对我来说至关重要.
不知怎的,我不能让zlib.crc32和zlib.adler32在Windows XP Pro 64bit机器上使用大于4GB的文件.我怀疑我在这里达到了32位的限制？使用hashlib.md5我可以得到一个结果,但问题是速度.为4.8GB文件生成md5大约需要5分钟.任务管理器显示该进程仅使用一个核心.
我的问题是:
PS:我正在开发类似于"资产管理"系统的东西,有点像svn,但资产包括大型压缩图像文件.文件有微小的增量变化.检测变化和错误检测需要散列/校验和.
这是一个算法选择问题，而不是一个库/语言选择问题！
看来主要有两点需要考虑：
显然，第二个问题的答案类似于“允许一些假阴性”，因为任何32 位散列相对于 4Gb 消息的可靠性，即使在适度嘈杂的通道中，实际上也不是绝对的。
假设可以通过多线程改进 I/O，我们可能会选择不需要对完整消息进行顺序扫描的哈希。相反，我们可以并行处理文件，散列各个部分，然后组合散列值或附加它们，以形成更长、更可靠的错误检测设备。
下一步可能是将这种文件处理形式化为有序部分，并按原样传输它们（在接收方的一端重新粘合在一起）。这种方法，连同有关文件生成方式的附加信息（例如，它们可能通过附加专门修改，如日志文件），甚至可以限制所需的散列计算量。这种方法增加的复杂性需要权衡快速 CRC 计算的愿望。
附注：Alder32是不局限于特定阈值之下消息大小。它可能只是 zlib API 的一个限制。（顺便说一句，我发现的关于 zlib.adler32 的参考使用了一个缓冲区，嗯……在我们的大量消息的上下文中应该避免这种方法，有利于流式处理：从文件中读取一点，计算，重复。 .)
由于 MD5 的本质，您不可能使用多个核心来计算大文件的 MD5 哈希值：它期望将消息分成块并按严格的顺序输入哈希函数。但是，您可以使用一个线程将文件读入内部队列，然后在单独的线程中计算哈希值，这样。但我认为这不会给你带来任何显着的性能提升。
处理大文件需要很长时间的事实可能是由于“无缓冲”读取造成的。尝试一次读取 16 Kb，然后将内容分块输入哈希函数。