Srovnání kompresních nástrojů - UPDATE

4.4.2010 16:49 | Přečteno: 1756× | linux | | poslední úprava: 5.4.2010 10:10

Nedávno avizovaný přechod Archlinuxu na balíčkování pomocí XZ mě donutil podívat se na zoubek všemožných komprimátorů a trošku je otestovat.

Testovány byly nástroje GZIP, BZIP2, XZ, ZIP, 7Z a RAR. Celý článek jsem bohužel musel vydat jinde, zda se mi nepodařilo zobrazit správně tabulky.

UPDATE
Všímavými čtenáři jsem byl upzorněn na to, že i TAR má určitý kompresní poměr, takže jsem upravil tabulku, aby více odpovídala realitě. Doplněn byl ještě druhý řádek nástroje 7Z, tentokrát s nastavenými parametry pro lepší kompresi.

       

Komentáře

[abr]

V clanku chybi jedna -nevyznamna- promenna (testovaci masinka).

[brk]

A na co je dobré vědět, že 100MB nespecifikovaných dat komprimuje sestava X.Y n sekund? Pro mne jsou spíš důležitá procenta a skutečnost, že testy byly provedeny na identickém železe.

[Michal Kubeček]

Zvolený hardware může výrazně ovlivnit i ty poměry. Namátkou si vzpomínám třeba na dost zásadní rozdíly při porovnání propustností AES, DES a 3DES na 32-bitových a 64-bitových systémech (a dokonce i na 64-bitových AMD vs. Intel). Ještě výraznější rozdíly je možné zaznamenat v případě, že implementace některého z algoritmů umí rozložit zátěž na víc procesorů.

[Dundee5]

Neuváděl jsem to celkem záměrně. Každý rýpal by pak mohl halekat, že on má tutéž sestavu, ale jede mu to o 3% rychleji apod. Důležité je, že celkově ten test vyjde nějak, ale dílčí hodnoty bych moc neřešil.

[vlastikroot]

Tak pro orientaci ... Vzhledem k tomu, že čimdáltim víc plnohodnotných linuxových mašin je třeba jen 200MHz MIPS, třeba časy dekomprimace jsou tězká věc (mě stači i rozbalování menších tar.bz2 na 624MHz PXA270).

[Dundee5]

Rychlost dekomprimace určitě pociťují i uživatelé normálních PC. Přeje jen je rozdíl, jestli se při aktualizaci systému každý balíček rozbaluje 2s nebo 15s (trochu nadsázka).

Proto mi přijde dobrý formát XZ, který dekomprimuje velmi rychle (v porovnání s BZIP2 třeba).

[Mandarinka]

Není XZ jen a pouze další archivátor používající lzma ve vlastním nekomaptibilním formátu? 7z má aspoň slušnou podporu.

P.S. právě lzma myslím má poměrně rychlou dekompresi.

[Petr Tomášek]

Ne. XZ je upravená (optimalizovaná) LZMA komprese (nekompatibilní s původním LZMA). Rozdíl mezi XZ a původní LZMA je zanedbatelný, nicméně, proč nevyužít lepší z nich, že?

[Dundee5]

Ten rozdíl zas tak zanedbatelný není. Kompresní poměr a rychlost komprese jsou téměř identické, ale rychlost dekomprese je u XZ podstatně lepší.

[Jary]

Všimněte si také toho, že kompresní nástroje, které umějí archivovat adresáře (zip, 7z, rar), dosahovaly daleko lepších výsledků, pokud se jim předal místo adresáře pouze jeden TAR archív.

Jak je tohle možné? Řadí snad TAR soubory podle přípony, nebo typu a konpresory ne? Kdybych dělal kompresor, tohle by byla jedna z optimalizací, kterou bych udělal jako první, protože si myslím, že to u většiny kompresních algoritmů bude velmi nápomocné.

[JS]

Ja tedy nevim o nastroji (na Linuxu), ktery pred tarovanim spravne seskladal podobne soubory k sobe tak, aby se pak daly lepe zkompresovat. Idealne by to byl "plugin" do taru podobne jako gzip nebo bzip2.

[Dundee5]

Bohužel to vypadá, že všechny tyto nástroje komprimovaly jednotlivé soubory, což je samozřejmě mnohem méně efektivní, než komprimovat celý balík najednou. Když se tomu předal TAR archiv, mohl ten kompresní nástroj lépe sestavit slovník.

[chrono]

7z (a aj rar) má parameter na vytváranie "solid" archívov (a teda, súbory sa najskôr "spoja" a až potom komprimujú, takže tar nie je potrebný). To ale potom znamená, že ak niekto chce len posledný súbor, musí sa rozbaliť celý balík.

Inak bolo by zaujímaví pri 7z použiť aj iné kompresie (napr. aj lzma).

[Dundee5]

Díky za postřeh, o této vlastnosti jsem nevědel.

[Mandarinka]

7-zip (alespoň na w32, u p7zip si nevzpomínám) skutečně při použití solid komprese seřadí soubory podle přípony. Jen upozorňuju, že je třeba při dekomprimaci souboru rozbalit všechny předcházející soubory, takže to může být docela náročné :)

[Jary]

No jistě! Že mě to nenapadlo hned.

[Jakub Lucký]

Díky za test...

Ale když už jsme u tohohle tématu, tak by mě zajímalo, jestli neexistuje nějaký šikovný způsob, jak zabalit velké množství dat a pak z toho rychle a nenáročně extrahovat části (příklad: celé /etc a pak z něj tahat nějaký konfigurák)... Protože u tar.* je neštěstí, že se informace o uložených souborech uloží do .tar a při zkoumání souboru se to nejdřív musí celé (? info not guaranteed) rozbalit a pak teprv má člověk seznam souborů k dispozici

[Kvakor]

Stačí použít cokoliv, co komprimuje soubory samostatrně, tj. cokoliv mimo TARu a solid archívů (u Raru a 7Zipu). Záleží jen na rozhranní archivátoru/filemanageru. V Linuxu je ještě navíc možnost připojit archiv přes FUSE jako souborový systém, nebo k němu tak přistupovat přes obdobné rozhranní deskotpových přostředí (GVFS v Gnome, KIO v KDE).

Ale moje nejoblíbenější linuxové řešení je SquashFS, komprimovaný read-only souborový systém, který nemá omezení CramFS a umí mimo Gzipu používat i LZMA (zatím není součástí vanila verze, musí se patchovat). Je to asi nerychlejší metoda přístupu k souborůl v archivu (ovladač je v jádře) a archiv je i při použití stejné kompresni metody většinou menší než TAR, protože efektivněji ukládá metadata (komprimuje inody) a navíc dokáže detekovat duplicitní soubory. Jediná nevýhoda je nutnost archiv před přístupem namountovat přes loopback

[Jakub Lucký]

Hm, SquashFS by mohl být dobrý zálohovací systém... Ty TARy jsou v tomhle fakt naprd...

[pavlix]

Takhle přijde jinej rejpal, a zeptá se tě:

1) Co je to úroveň dekomprese (definice) a podle čeho ji počítáš?

2) Jak je možné, že úroveň dekomprese (bez ohledu na měřítko) dává 0% v případě změny 100M dat na 97M dat

Tyhle otázky spolu očividně blízce souvisí... na první pohled mi to přijde, že vidím prosté plácání a ne nějaké definované porovnání.

[Dundee5]

1) Myslíš úroveň komprese? Přejmenuju to na "úsporu místa", to je asi čitelnější.

Díky za postřehy. Do článku to doplním/opravím.

[pavlix]

Díky, to bude fajn, když to nějak zadefinuješ, co ty procenta vlastně znamenají...

[Robert Krátký]

zda se mi nepodařilo zobrazit správně tabulky

V čem byl prosím problém? Tabulky z tvého zápisku jsem dokázal vložit do zdejšího systému bez problému.

[Dundee5]

Nepodařilo se mi zobrazit rámečky v tabulce (parametr rules je zakázán). Data pak byla dost nečitelná.

[Robert Krátký]

Parametr rules není potřeba, když nechceš zobrazení omezovat jen na některé rámečky. Rules=all je výchozí nastavení. Zkus si svou tabulku sem do blogu vložit ve stejné podobě, jen s vynechaným rules - bude normálně ohraničená.

(Nicméně díky za upozornění - parametr rules povolíme.)

[Dundee5]

Asi bych si měl zopakovat základy HTML :)

[|🇵🇸]

OK, možná jsi mě dostal. Používám ZIP, 7Z nebo TAR + GZIP podle toho, komu jsou data určena. Není to totiž od věci, otevře-li daný archiv. XZ se mi fakt začíná líbit. Jenže jaká je pro to podpora na různých systémech?

[|🇵🇸]

Jo a nejsou to kompresní nástroje?

[Dundee5]

Máš pravdu, komprimovací nástroje se asi moc nepoužívá :)

XZ má dobrou podporu jen na Unixu myslím. Na Windows je podpora jen experimentální.

[|🇵🇸]

Jak je to s balíčky v různých distribucích, jsou tam by default? Koukám, že Ubuntu KuKluxKlan je nainstalováno akorát liblzma0 (prý používá xz jako výchozí formát), s xz zjevně souvisí už jen balíček xz-utils, který nainstalován běžně není, je ve verzi 4.99 (nebo tak nějak, prostě nestabilní), navíc se pere s lzma.

[Dundee5]

Podpora pro XZ je v přímo v nástroji TAR a to od verze 1.22. V Debianu Lenny je zatím verze 1.20. V Ubuntu je podle všeho 1.22, v Arch Linuxu je 1.23, takže tam je podpora dobrá.

[|🇵🇸]

Fakt? Každopádně ten Lenny (a pravděpodobně CentOS) to zabíjí.

[Dundee5]

Od verze 1.20 je v TARU podpora LZMA, což také není špatné.

[petr_p]

Test zcela opomíjí paměťovou náročnost. Zcela v souladu s teorií účinnější algoritmy sežerou více paměti. Možná že to dnešní rozmazlené uživatele netrápí, ale lzma/xz si dokáže vzít řádově desítky až stovky megabajtů. A to xz-utils ještě neumí paralelizaci.

[Kvakor]

To ještě nic není, PAQ, který má asi nejlepší kompresní poměr pro běžná data (vyhrál několikrát Huttnerovu cenu), může v některých verzích schramstnout i přes gigabyte paměti. Ani časová náročnost není o nic méně šílená ...

[petr_p]

A přitom je to tak jednoduché: wget -O - 'http://download.wikipedia.org/enwiki/20060303/enwiki-20060303-pages-articles.xml.bz2' | bzcat | head -c 1GB :D

[Dundee5]

A opomíjí ji záměrně. Nedostatek paměti myslím dnes nikoho moc netrápí. Při dnešních cenách RAM je nějaká ta stovka MB navíc celkem zanedbatelná. Jiné by to samozřejmě bylo u embeded zařízení, ale o tom ten článek rozhodně není.

Daleko víc uživatele určitě trápí rychlost dekomprese a velikost archivu (u softwarových balíčků), případně ještě rychlost komprese (při zálohování).

[R]

Neda sa vsetko prepocitavat na peniaze. Kup si kludne 16GB RAM, ale skus to dat do netbooku.

[hajma]

sorry, ale toto je srovnani, ktere bylo namiste tak mozna kolem roku 1996

Clanky tohoto typu jsou na netu na kazdem rohu, v tom tvem navic chybi popis metodiky, takze jeho vypovidaci hodnota se blizi nule. Skoda.

Jestli mas cas na takove veci, nechtel bys radeji otestovat pbzip2, pigz a dalsi nastroje, ktere opravdu dokazi vyuzit moznosti aktualniho hardware?

[Semo]

Naco ho sprdavat, ked ho mozme rovno zabit? To ho nauci si dovolovat robit testy, holomka.

[Michal Kubeček]

Ono už se zase nesmí kritizovat?

[pavlix]

Ona už se nesmí kritizovat kritika?

[Dundee5]

A nechtěl bys o tom napsat test ty? :)

Já o těchto nástrojích slyším poprvé.