Test rychlosti kompresních programů

WebUpd8 vydal článek srovnávající rychlost komprese a dekomprese v závislosti na použitém kompresním programu. Nejlépe ze srovnání vychází lzop.

9.7.2011 23:09 | Migi | Zajímavý článek

Komentáře

[לך לעזה]

chyba lávky, cat je rychlejší

[MX]

No, ano ... neresili tam kompresni pomer, takze ten test je uplne k prdu.

[Jirka P.]

Navíc tam "komprimovali" /dev/zero, neřešili cacheování atd. Test k ničemu.

[stativ]

A pak tu lidi nadávají na phoronix.

[MX]

btw bacha na fakt, ze kdyz jsou ty data dost velke, tak by ten kompresni program mohl byt rychlejsi nez je primo kopirovat (zapis je relativne pomaly). Zapisovalo by se pak mensi mnozstvi dat a navic zapis a komprese by mohly probihat paralelne (hlavicka by nelitala po disku jenom tam a zpatky). Pak tu jde vzit v uvahu, ze tam jsou disky dva a kdesi cosi ...

[T-T]

Nemohl, stejně je musíš rozbalit

[David Watzke]

Tam ale platí totéž, čteš méně dat a zapisuješ jich stejně -> opět to může být rychlejší.

[Hynek (Pichi) Vychodil]

Přesně tak. Rychlost dekomprese lzop se běžně pohybuje na rychlosti čtení z paměti, na moderním HW může být i rychlejší. To se pak pro některé účely vyplatí držet data komprimovaná v paměti a dekomprimovat do cache CPU v momentě, kdy jsou potřeba.

[omg]

a vida. prece jen tu jeste zustal nekdo komentovat, kdo pouziva obcas i to uvnitr hlavy... no kazdopadne vsechny algoritmy maji svoje + a - a na ruznych datech a ruznym hw se budou vysledky lisit vice nez zanedbatelne. at uz je algoritmus citlivy jen na rychlost zaznamoveho zarizeni, jiny hlavne na cpu a dalsi kvuli prostorove slozitosti na rychlost a velikost pameti a samotna ucinnost komperese a vyhodnost pouziti u nekterych vyjmecnych pripadu je pak zalezitosti vhodneho vyberu komprimovanych dat. zaver? DO TEST IT ON YOUR OWN DATA AND HARDWARE.

[mirefek]

Vzdyt to tam pisou -- Obviously, less is better ...

[Limoto]

Nečekaně...

[werWER]

U kompresních programů mě zajímá dosahovaný kompresní poměr. To neotestovali.

[Xerces]

A ještě je zajímavý, zda existuje dekompresní algoritmus.

[Habo]

Jj, pigzip...

[omg]

rm ma neprekonatelny kompresni pomer vymenou za absenci dekomprese.

[vencas]

barf má poměr stejný jako rm; na rozdíl od něj však dokáže soubor opět rozbalit.

[Petr Tomášek]

jo, s tím rozdílem, že barf kóduje data do názvu souboru

[Andrej]

if the first byte is n-2 then remove it

Method n (2-257) is indicated by an extension of the form .x[0-9][a-z] as a base 26 encoding of n-2. For example, method 2 (.x0a) removes a leading 0 byte, method 3 (.x0b) removes a leading 1 byte, up through method 257 (.x9v) which removes a leading 255 byte.

inymi slovami je to prenos prveho bajtu obsahu suboru do jeho nazvu (a teda ulozenie v ramci metadat suboroveho systemu). disku to nepomoze len sa tie data ulozia na ine miesto. v uctovnictve a to nazyva skryty dlh, v makroekonomike deficit statneho rozpoctu, sedliackym rozumom sa to da jednoducho pomenovat ako podvod.

[Dundee5]

Srovnání, kde je zahrnut i kompresní poměr, je tu:

Srovnání kompresních nástrojů

[Hynek (Pichi) Vychodil]

A lzop je kde?

[BostX]

Ked najprv 10 sekund tukam do klavesnice, dva-tri krat sa pomylim, rezignujem natukam --help, este raz rezignujem a zagooglim na nejake examples. Magori!