到底 reiser4 的 cryptcompress 有沒有用? (下)

搞個測試還真不容易，如果我有多的 partition，就可以直接建個有 cryptcompress plugin 的 fs 來試，問題是誰會在自己硬碟留個 partition 不用的。借台 USB 外接硬碟? USB 本身頻寬太低了，無法反應 IDE 或 SATA 的真實狀況。

後來把這個實驗寫成 script，方便測不同檔案，cat, lzop, gunzip 都先預先執行過以減少 load 時間的差異
#!/bin/sh
rm test test.lzo test.gz
cp $1 test
lzop -1 test
gzip -1 test -c > test.gz
ls -l test test.lzo test.gz

echo "-----------------------------------------------------------------------"
echo "test"
./eatmem
sleep 10
cat --help >& /dev/null
time cat test > /dev/null

echo "-----------------------------------------------------------------------"
echo "test.lzo"
./eatmem
sleep 10
lzop --help >& /dev/null
time lzop -d test.lzo -c > /dev/null

echo "-----------------------------------------------------------------------"
echo "test.gz"
./eatmem
sleep 10
gunzip --help >& /dev/null
time gunzip test.gz -c > /dev/null

結果大致與想像相同，檔案越大，能節省的時間越多。逐漸縮小測試檔 size，gzip 的方式很早就出現比沒壓縮慢的情況，除非將 CPU 升級，否則我是不考慮了。lzo 的表現則頗令人滿意，大檔案甚至會出現七、八倍效能的狀況，假設有支程式總共 link 五個 libraries，每個 library 從硬碟讀出平均節省 0.2 秒，那啟動速度就快整整一秒了，對大型程式改進一定更多。不過 lzo 的數據太漂亮，我也因此懷疑其可信度。索性拿已壓縮過的 .bz2 檔案來試，慘了，lzo 竟然也有速度比較快的時候，看來 lzop 的數據得要加乘某個數值才準。所以，我的測試只能先對 cryptcompress plugin 效能有個大概的底，想得到更真實的結果，還是乖乖弄個 partition 來玩吧。