原本是在查找 CRC簡單的實作方法
結果就看到有人測試使用zlib中的CRC效能遠比另一個CRC方法還要快 (參見)
所以開始對zlib好奇起來, 順便測試一下壓縮
但原來 zlib 和 gzip 為相同方法實作 (是不是相同核心我就不知道了)
但好奇心趨使下測試一下zlib在壓縮string在不同level下的效能
(生手症狀)
測試方法
1. 測試"等級"由 0 到9依序
timeit.Timer(stmt='len(zlib.compress("s"*10000, <等級>))', setup='import zlib').timeit(20000)
2. s = "".join(map(str, [i for i in xrange(1000)]))
將 s 取代 "s"*10000
僅測試等級0, 3, 9
3. 各別測試壓縮大小
測試結果
0 >> 0.7104859352111816 >> 1.597 >> 38906
1 >> 0.36516880989074707
2 >> 0.36100006103515625
3 >> 0.35786986351013184 >> 2.036 >> 19221
4 >> 1.0243659019470215
5 >> 1.0058510303497314
6 >> 1.0081779956817627
7 >> 1.0100719928741455
8 >> 1.008162021636963
9 >> 1.033383846282959 >> 2.100 >> 18527
結論
對於結果有兩點意外
對於壓縮不是很清楚的我現在才知道
原來不壓縮本身也是個負擔
連小壓縮都比沒壓縮還要快
另外壓縮等級3到等級4看來有個門檻
可能是壓縮方法改變
難怪壓縮預設等級通常為3
猜想為因為壓縮字典大小的關係
在第一個測試中字典太小了以至於計算時間也減少
所以第2測試和第3測試就恢復正常值了
壓縮比例也很符合官方公佈的數據.....
另外補充
這件事情讓我想起之前在壓縮非常大的log檔時 (約 800MB)
測試了一下tar -zcvf 和 tar -jcvf 的效能及效果
gz 壓縮率約為 8% 60MB, bz2 壓縮率約 5% 30MB
但是時間 gz 1分鐘 bz2 竟要6分鐘阿阿~~~
在Server CPU時常需要消耗CPU的情況下還是選擇gz就好了 Orz
沒有留言:
張貼留言