发现错误!我read
只吃了一大块,然后什么也不做!
改变了
with open(largetestfile, 'rb') as f:
read_data = f.read(blk_size_to_read)
filehash.update(read_data)
至
with open(testfile, 'rb') as f:
while (True):
read_data = f.read(blk_size_to_read)
if not read_data:
break
filehash.update(read_data)
解决问题。
更新:
我运行了上面程序的一个稍微修改过的版本,以确定在增量使用 update() 查找给定文件的哈希时要使用的最佳缓冲区大小。我还想确定增量散列是否有任何好处,而不是一次性计算文件的散列(内存限制除外)。
我为此创建了 20 个文件(带有随机数据),文件大小从 4096 字节开始,最大为 2.1 GB。这些文件中的每一个的 md5 散列是使用缓冲区大小开始2**6
字节(64 字节 - 块大小)到2**20
字节计算的。使用 timeit 每个都运行了 100 次,并获得了记录最短执行时间的执行时间。还记录了一次对整个文件进行哈希计算的执行时间。
结果如下...
FileName Filesize Chunksize Chunked Time Complete Time %diff
file5.txt 4096 4096 0.0014789 0.0014701 -0.60%
file6.txt 8192 524288 0.0021310 0.0021060 -1.19%
file7.txt 16384 16384 0.0033200 0.0033162 -0.12%
file8.txt 32768 65536 0.0061381 0.0057440 -6.86%
file9.txt 65536 65536 0.0106990 0.0112500 4.90%
file10.txt 131072 131072 0.0203800 0.0206621 1.37%
file11.txt 262144 524288 0.0396681 0.0401120 1.11%
file12.txt 524288 1048576 0.0780780 0.0787551 0.86%
file13.txt 1048576 1048576 0.1552539 0.1564729 0.78%
file14.txt 2097152 262144 0.3101590 0.3167789 2.09%
file15.txt 4194304 65536 0.6295781 0.6477270 2.80%
file16.txt 8388608 524288 1.2633710 1.3030031 3.04%
file17.txt 16777216 524288 2.5265670 2.5925691 2.55%
file18.txt 33554432 65536 5.0558681 5.8452392 13.50%
file19.txt 67108864 65536 10.1133211 11.6993010 13.56%
file20.txt 134217728 524288 20.2226040 23.3923230 13.55%
file21.txt 268435456 65536 40.4060180 46.6972852 13.47%
file22.txt 536870912 65536 80.9403431 93.4165111 13.36%
file23.txt 1073741824 524288 161.8108051 187.1303582 13.53%
file24.txt 2147483648 65536 323.4812710 374.3899529 13.60%
Chunked Time
是文件被分解成chuck并递增hased时的执行时间;这Complete Time
是一次对整个文件进行哈希处理时的执行时间。这%diff
是分块时间和“完成时间”之间的百分比差异。
观察:
- 对于较小的文件大小,块大小几乎总是等于文件大小,采用任何一种方法似乎都没有优势。
- 对于较大的文件(33554432 (
2**25
) 字节及以上),使用增量方法而不是一次性散列整个文件似乎有相当大的性能优势(更短的时间)。
- 对于较大的文件,最好的块/缓冲区大小是 65536 (
2**16
) 字节
备注:python 2.7.3;Ubuntu 12.06 64 位;8 Gigs RAM 用于此的代码可在此处获得... http://pastebin.com/VxH7bL2X