Článek
ZIP má pověst univerzálního tlačítka „zmenšit“. Označím soubory, zabalím je a čekám, že archiv bude menší. Jenže 100 MB není pro kompresor pokaždé stejných 100 MB. Rozhoduje hlavně to, co je uvnitř a zda už daný formát kompresi použil předtím.
Abych to neřešil jen teoreticky, postavil jsem tři kontrolované datové sady o zhruba stejné velikosti: prostý text, sadu JPEG obrázků a jedno H.264 video. Všechny jsem zabalil stejným postupem do ZIPu s metodou DEFLATE a stejnou úrovní komprese. Každý test jsem spustil třikrát a u času použil prostřední hodnotu.
Metodika: tři různé typy dat, jeden ZIP
Textová sada měla přesně 100 000 000 bajtů. Šlo o opakující se český text s drobnými změnami, tedy materiál, ve kterém může bezeztrátový kompresor snadno nacházet opakované vzory.
Fotografická sada měla 100 586 431 bajtů a obsahovala 36 syntetických testovacích JPEG snímků v rozlišení 1600 × 1200. Nešlo o moje osobní fotografie a ani to nepředstírám: vytvořil jsem kontrolovaný obrazový corpus právě proto, aby vstupní velikost byla srovnatelná a test byl opakovatelný.
Video mělo 104 357 854 bajtů. Šlo o šestnáctisekundový testovací obraz v H.264/MP4 s vysokým datovým tokem, vytvořený tak, aby vstupní soubor zůstal přibližně ve stejném stokilomegabajtovém pásmu.
Pro všechny tři kategorie jsem použil Python zipfile, běžnou metodu ZIP_DEFLATED a compresslevel 6. Oficiální dokumentace Pythonu potvrzuje, že ZIP_DEFLATED používá zlib/DEFLATE a že úroveň komprese lze nastavovat v rozsahu 0 až 9.
Text: 100,00 MB -> 0,39 MB
Největší rozdíl přišel okamžitě. Sto milionů bajtů textu se zabalilo na 388 219 bajtů, tedy přibližně 0,39 MB. Úspora vyšla na 99,61 %. Medián času ze tří pokusů byl 0,33 sekundy.
Tak extrémní výsledek není univerzální vlastnost každého textového souboru. Můj testovací corpus obsahoval hodně opakujících se struktur, což je přesně situace, ve které DEFLATE exceluje. Princip je ale důležitý: prostý text obvykle ještě není předem ztrátově ani bezeztrátově stlačený a kompresor v něm často najde velké množství opakování.
JPEG: 100,59 MB -> 99,84 MB
U obrázků se kouzlo téměř vytratilo. Vstupních 100,59 MB JPEGů skončilo jako ZIP o velikosti 99,84 MB. Rozdíl byl jen 743 878 bajtů, tedy přibližně 0,74 %. Medián zabalení byl 2,67 sekundy.
Důvod není v tom, že by ZIP „neměl rád fotky“. JPEG už sám používá vlastní kompresi obrazu. ZIP nad ním proto často dostane data, ve kterých nezůstává tolik snadno využitelných opakování. Může ještě ubrat drobnosti, ale zázračný druhý kompresní průchod se nekoná.
H.264 video: 104,36 MB -> 104,39 MB
Nejzábavnější výsledek přišel u videa. Vstupní MP4 mělo 104 357 854 bajtů, hotový ZIP 104 388 434 bajtů. Archiv tedy nebyl menší, ale o 30 580 bajtů větší. Rozdíl představuje asi 0,03 % vstupní velikosti. Medián času činil 2,25 sekundy.
To je logický konec situace, kdy další DEFLATE prakticky nemá co získat. H.264 už pracuje s velmi agresivní kompresí obrazu v čase. Pokud ZIP nenajde dost dalších opakujících se bajtových vzorů, zůstane téměř stejná velikost a navrch přibude režie samotného ZIP archivu: hlavičky, adresář položek a další metadata.
Rychlost není hlavní pointa tohoto testu
Časy vypadají přesně, ale nejsou přenositelné na každý počítač. Záleží na procesoru, úložišti, operačním systému, počtu souborů i tom, co mezitím dělá systém. Proto je beru jen jako doprovodný údaj mého konkrétního běhu, ne jako benchmark, podle kterého má být posuzován jiný notebook.
Zajímavější je stabilita velikosti: všechny tři opakované běhy v každé kategorii skončily shodnou velikostí ZIPu. Měnil se čas, nikoli výsledek komprese.
ZIP není nový kodek pro fotku ani video
Praktická lekce je jednoduchá. ZIP umí výborně zabalit hodně typů dat do jednoho souboru a u nekomprimovaného nebo dobře opakovatelného obsahu může velikost dramaticky srazit. Není ale druhým JPEGem ani druhým H.264.
Když posílám složku fotek, ZIP je pořád užitečný kvůli pohodlí: jeden archiv se lépe přenáší než desítky souborů. Neměl bych ale automaticky očekávat, že 100 MB JPEGů zmizí na polovinu. A u moderního videa je klidně možné, že výsledek bude o pár kilobajtů větší.
Takže ano: 100 MB je na disku pořád zhruba 100 MB. Pro kompresor je ale důležitější otázka, z čeho se těch sto megabajtů skládá. V mém měření rozdíl mezi textem a videem znamenal skoro celých 100 MB.
Zdroje a prameny
• Python 3 documentation – zipfile — použitá implementace testu; ZIP_DEFLATED, zlib a parametr compresslevel
• RFC 1951 – DEFLATE Compressed Data Format Specification — technický základ algoritmu DEFLATE a práce s literály a odkazy na dříve se vyskytující řetězce
