Confronto gzip, bzip2, xz, lzip, pbzip2, pigz e lbzip2

[Mario Vanoni]

Update 06-Dec-2009

2 identical machines with each 2 HD's SATA 1TB/32MB on-board memory
Core 2 Dual 1866MHz 6320 with 4096kB L2 cache, 4GB main memory
Slackware 12.2 with ext2 as FS,
static kernel 2.6.29.4, 2.6.30 (*) and 2.6.31.6-bfs311 (**)

Codice: Seleziona tutto

gzip 1.3.12
bzip2 1.0.5
xz 4.999.8beta
lzip 1.5
lzip 1.6 (*)
pbzip2 1.0.5 (*)
pigz 2.1.4 (*)
lbzip2 0.19 (**)

dir with 22197 files from 1.2 to 566MB, du -hs 869GB

gzip -9 -f -v * time 28 hours, du -hs 731GB
bzip2 -9 -f -v * time 64 hours, du -hs 651GB
xz -9 -f -v * time 208 hours, du -hs 622GB
lzip -9 -f -v * time 341 hours, du -hs 621GB
pbzip2 -9 -f -v * time 35 hours, du -hs 651GB (*)
pigz -9 -f -v * time 19 hours, du -hs 732 GB (*)
lbzip2 -9 -f -v * time 42 hours, du -hs 651GB (**)

time gzip -c -d 1.2MB_file.gz > /dev/null 0m0.026s, 3 tests
time bzip2 -c -d 1.2B_file.bz2 > /dev/null 0m0.116s, 6 tests
time xz -c -d 1.2MB_file.xz > /dev/null 0m0.150s ... 0m0.113s, 9 tests
time lzip-1.5 -c -d 1.2MB_file.lz > /dev/null 0m0.144s ... 0m0.126s, 9 tests
time lzip-1.6 -c -d 1.2MB_file.lz > /dev/null 0m0.122s ... 0m0.118s, 9 tests
time pbzip2 -c -d 1.2B_file.bz2 > /dev/null 0m0.120s, 6 tests (*)
time pigz -c -d 1.2B_file.bz2 > /dev/null 0m0.015s, 6 tests (*)
time lbzip2 -c -d 1.2B_file.bz2 > /dev/null 0m0.140s, 3 tests (**)

gzip -c -d 566MB_file.gz > /dev/null about 14 seconds, 3 tests
bzip2 -c -d 566MB_file.bz2 > /dev/null about 72 seconds, 6 tests
xz -c -d 566MB_file.xz > /dev/null about 57 seconds, 6 tests
lzip-1.5 -c -d 566MB_file.lz > /dev/null about 65 seconds, 6 tests
lzip-1.6 -c -d 566MB_file.lz > /dev/null about 63 seconds, 6 tests
pbzip2 -c -d 566MB_file.bz2 > /dev/null about 36 seconds, 6 tests (*)
pigz -c -d 566MB_file.bz2 > /dev/null about 8 seconds, 6 tests (*)
lbzip2 -c -d 566MB_file.bz2 > /dev/null about 68 seconds, 5 tests (**)

gzip -d -v *.gz time 10 hours, du -hs 869GB
bzip2 -d -v *.bz2 time 33 hours, du -hs 869GB
xz -d -v *.xz time 28 hours, du -hs 869GB
lzip -d -v *.lz time 44 hours, du -hs 869GB
pbzip2 -d -v *.bz2 time 20 hours, du -hs 869GB (*)
pigz -d -v *.gz time 9 hours, du -hs 869GB (*)
lbzip2 -d -v *.bz2 time 30 hours, du -hs 869GB (**)


[submax82]

sarebbe interessante provare p7zip ... ma forse è la stessa cosa di xz o lzma boooo

[conraid]

Mario, dai tuoi test si evince che quello che dice Pat e quello che dicono quelli del kernel (adesso è possibile fare l'immagine in bzip2 e lzma) è vero
LZMA è il più lento in compressione, ma il più veloce (dopo gzip naturalmente) in decompressione. E comprime più degli altri.
Quindi se rallenta il lavoro dei "pacchettizzatori" agevola quello degli utenti che si ritrovano più software e non rallentamenti come con altri compressori.
Del resto se era stato scelto da slax e da suse, ed ora da Slackware e kernel un motivo ci sarà.
Poi naturalmente ha i suoi pro ed i suoi contro, ed ognuno sceglie in base alle proprie esigenze.

[Mario Vanoni]

sarebbe interessante provare p7zip ... ma forse è la stessa cosa di xz o lzma boooo

Sono abbastanza pazzo (l'eta`!!!),
se mi passi un link per Linux,
magari lo provo sotto le stesse condizioni.

[ponce]

c'e' da dire che il rapporto di compressione di default di lzma, 7 (se non si specificano espressamente livelli di compressione piu' elevati), comprime gia' piu' di bzip2 ed e' parecchio piu' veloce del 9.
penso che i pacchetti siano compressi con 7 (cosi' come prima usavano il valore di default di bzip2).

[conraid]

c'e' da dire che il rapporto di compressione di default di lzma, 7 (se non si specificano espressamente livelli di compressione piu' elevati), comprime gia' piu' di bzip2 ed e' parecchio piu' veloce del 9.
penso che i pacchetti siano compressi con 7 (cosi' come prima usavano il valore di default di bzip2).

prima usavano gzip -9c, adesso

Codice: Seleziona tutto

$TAR cvf - . | xz -c > ${TARGET_NAME}/${TAR_NAME}.${EXTENSION}

xz

Codice: Seleziona tutto

  -0 .. -9            compression preset; 0-2 fast compression, 3-5 good
                      compression, 6-9 excellent compression; default is 6


Mario, devi rifare il test

[Mario Vanoni]

sarebbe interessante provare p7zip ... ma forse è la stessa cosa di xz o lzma boooo

Sono abbastanza pazzo (l'eta`!!!),
se mi passi un link per Linux,
magari lo provo sotto le stesse condizioni.

Scartato, man 7z:

Backup and limitations
DO NOT USE the 7-zip format for backup purpose on Linux/Unix because :
- 7-zip does not store the owner/group of the file.

[Mario Vanoni]

Mario, devi rigare il test

Non capisco cosa intendi per "rigare",
se intendi rifare i test con l'opzione -6,
dimenticalo!

[conraid]

Mario, devi rigare il test

Non capisco cosa intendi per "rigare",

ovvia, ho sbagliato tasto

se intendi rifare i test con l'opzione -6,
dimenticalo!

era una battuta dai

[ponce]

(cosi' come prima usavano il valore di default di bzip2).

prima usavano gzip -9c

dormo in piedi, scusa

[conraid]

(cosi' come prima usavano il valore di default di bzip2).

prima usavano gzip -9c

dormo in piedi, scusa

troppi pochi ponci? :P

[ponce]

dici bene, ne bevo uno alla tua e a quella di mario (ho il vittori e la macchinetta da espresso a casa )

[submax82]

sarebbe interessante provare p7zip ... ma forse è la stessa cosa di xz o lzma boooo

Sono abbastanza pazzo (l'eta`!!!),
se mi passi un link per Linux,
magari lo provo sotto le stesse condizioni.

Scartato, man 7z:

Backup and limitations
DO NOT USE the 7-zip format for backup purpose on Linux/Unix because :
- 7-zip does not store the owner/group of the file.

ok ma se prima usi tar e poi comprimi il tar (come nei pacchetti slack) sei a posto ed è una bomba in compressione, una volta ho usato l'equivalente per win. Trovi già il pacchetto su slacky

[Mario Vanoni]

ok ma se prima usi tar e poi comprimi il tar (come nei pacchetti slack) sei a posto ed è una bomba in compressione, una volta ho usato l'equivalente per win. Trovi già il pacchetto su slacky

Grazie, ma mi servono i files in tempo reale:
compressore -c -d | programma_che_li_usa
e` gia` rallentato non di poco,
con tar non e` molto pratico ...
programma_che_li_usa file
e` immediato, quindi
ho deciso di _non_ comprimere i files,
piuttosto nuovi HD da 2TB, se crescono troppo.

Idee di altri nel forum, raid con 4 HD da 500GB,
prezzo forse minore/simile,
ma consumo energetico (in Watt) superiore,
quindi problemi di raffreddamento, alimentazione ecc.

Problema crash?
2 HD, uno la copia dell'altro,
seconda macchina copia identica della prima.
Murphy sia clemente!

[Mario Vanoni]

Mandata una mail a
http://tukaani.org/contact
per chiedere se c'e` un pxz in vista,
se rileggete il mio primo post,
pbzip2 e` molto interessante con piu` processori.