Giorni fa Google sul blog per sviluppatori ha annunciato Zopfli sempre seguendo il filone della velocizzazione del Web. Lo studio fatto e il paper scritto dal Jyrki Alakuijala e E Lode Vandevenne mette in evidenza le peculiarità del nuovo algoritmo di compressione rispetto ai vari e più affermati. Il documento con i benchmark misura le performance di Zopfli e le compara con altre implementazioni di compressioni compatibili con deflate. Verrà mostrato che Zopfli ha il miglior livello di compressione rispetto a tutti gli altri algortimi di compressione presi in esame.
Il risultato finale e interessante è che Zopfli impiega molto più tempo nella compressione, ma la velocità di decompressione è allo stesso livello degli altri.
In breve che cosa è Zopfli e in cosa consiste lo studio
Zopfli è un nuovo compressore compatibile con deflate ed è ispirato a WebP, il nuovo formato di compressione lossless sviluppato da Google (qui un articolo chiaro su WebP che vi può aiutare a comprenderlo meglio). Il fatto che Zopfli sia compatibile con deflate lo rende compatibile anche con zlib e gzip. Questo significa che Zopfli è compatibile con tutti i browser moderni e di conseguenza può essere adottato in modo diffuso senza complicazioni a differenza di WebP che è supportato solamente da Chrome, almeno sino ad oggi 16-03-2012.
Nello studio di Alakuijala e Vandevenne verrà comparato Zopfli con zlib, 7-zip e kzip a livello di densità di compressione e di velocità di compressione/decompressione.
La compressione si basa sull’eliminazione di ridondanza dai dati. La ridondanza può essere per esempio data da simboli usati frequentemente o sequenze di simboli ripetute.
Più è piccola la dimensione compressa maggiore è la possibilità di salvare dati in meno spazio, trasferirli più velocemente e quindi velocizzare i tempi di caricamento delle pagine web. Inoltre, dimensioni più piccole danno un ulteriore vantaggio nel campo Mobile permettendo di risparmiare sul trasferimento dati e sul consumo della batteria. L’elevata densità dei dati viene ottenuta usando tecniche più esaustive di compressione che la rendono molto lenta, ma senza conseguenza nella velocità di decompressione.
Il metodo utilizzato nella ricerca
Sono stati scelti vari set di file per eseguire la compressione:
- un benchmark web centrico scaricando le homepage di 10000 dei siti più popolari restituiti dal Alexa – Link.
- Calgary Corpus che sono una collezione di piccoli testi e file binari comunemente usati per comparare gli algoritmi di compressione – Link
- Canterbury Corpus che è un corpus di compressione pensato per la compressione lossless – Link
- Enwik8 è stato sviluppato come un grande benchmark per la compressione di testi che consiste in 100 milioni di byte di Wikipedia Inglese – Link
Per far girare i benchmark è stato usato Ubuntu con un kernel 3.2.5 (x86_64) su un Dell Precision T3500 Intel Xeon CPU X5650 con 2.67 Ghz. Le versioni dei vari software usati sono
- Zopfli revision acc035299f8d
- gzip 1.4
- 7Zip (A) [64] 9.20
- kzip (release 20091108).
Il compilatore usato è gcc versione 4.6.3. Zopfli e kzip sono stati fatti girare con le impostazioni di default mentre gzip con 9 e 7zip con mm= Deflate mx= 9.
Risultati
I risultati ottenuti (Tabella 1) indica che Zopfli produce l’output più denso, ma più lento (Tabella 2) di tutti gli algoritmi testati. Il tempo di decompressione (Tabella 3) non subisce invece influenza tra i vari algoritmi testati.
Tabella 1. Dimensioni dei dati compressi nei 4 set di dati e con gli algoritmi di compressione scelti. L’output prodotto da Zopfli è di 3.7-8.3% più piccolo di quello di gzip-9.
| Benchmark | Corpus size | Gzip -9 | 7-zip | kzip | Zopfli |
|---|---|---|---|---|---|
| Alexa-top-10k | 693’108’837 | 128’498’665 | 125’599’259 | 125’163’521 | 123’755’118 |
| Calgary | 3’141’622 | 1’017’624 | 980’674 | 978’993 | 974’579 |
| Canterbury | 2’818’976 | 730’732 | 675’163 | 674’321 | 669’933 |
| enwik8 | 100’000’000 | 36’445’248 | 35’102’976 | 35’025’767 | 34’995’756 |
Tabella 2. Tempi di compressione per enwik8. Zopfli è 81 volte più lento del più veloce algoritmo gzip-9.
| Algoritmo di compressione | Tempo di compressione |
|---|---|
| Gzip -9 | 5.60 s |
| 7-zip -mm=Deflate -mx=9 | 128 s |
| kzip | 336 s |
| Zopfli | 454 s |
Tabella 3. Tempi di decompressione per i dati che erano stati compressi utilizzando “gzip -d” su enwik8. Il metodo usato è stato ottenuto facendo girare 9 volte e scegliendo il tempo medio. La differenza tra il più veloce e il più lento è di 2.5%.
| Algortimo di compressione | Tempo di decompressione per “gzip -d” su enwik8 |
|---|---|
| Gzip -9 | 934 ms |
| 7-zip -mm=Deflate -mx=9 | 949 ms |
| kzip | 937 ms |
| Zopfli | 926 ms |
Le conclusioni degli ideatori
Zopfli restituisce una dimensione di output più piccola tra gli algoritmi deflate-compatibili gzip (3.7-8.3%), 7-zip, a kzip, usando più tempo di CPU nella fase di compressione. Questo rende Zopfli ideale in quei casi in cui il costo di CPU è più piccolo in relazione alla dimensione di output. Questo uso può includere una compressione più densa dei contenuti statici per rendere i siti più veloci.
Nello studio si è cercato di trovare la più piccola dimensione possibile come risultato della compressione, e per questo tutti gli algoritmi sono stati eseguiti con il livello massimo di compressione. Zopfli può inoltre essere fatto girare con tempi più lunghi per ottenere maggiori livelli di densità di compressione, ma in questo caso sono stati usate le impostazioni di default.
Alla luce di questi risultati, secondo i suoi creatori Zopfli è ottimale per la compressione di contenuti statici e altri contenuti dove il costo del trasferimento dei dati e di consumo disco sono più elevati del costo di aumento tempo di CPU. Da quello che emerge Zopfli produce solitamente il miglior risultato di densità di compressione di qualsiasi altro algoritmo compatibile con deflate.
Zopfli è stato rilasciato opensource https://code.google.com/p/zopfli/ quindi si possono fare esperimenti.
Le considerazioni viste dall’esterno
Considerando i risultati ottenuti dai ricercatori sicuramente come anche evidenziato da loro si presta bene per alcuni casi d’uso e non in tutti. Effettivamente il livello di compressione sembra essere buono, ma il fatto che il tempo di compressione sia di 81 volte più lento è davvero un numero considerevole.
Speriamo che il lavoro dei due ricercatori porti Zopfli a migliorare per quanto riguarda la fase di compressione e allora diventerebbe davvero interessante l’adozione di questo algoritmo anche su più ampia scala. Prevedo che questo algortimo appena sarà più maturo verrà incluso in mod_pagespeed nella forma di filtro di compressione alternativo a deflate standard.
Appena il progetto sarà più maturo e con un minimo di documentazione mi riprometto di fare delle prove e dei test per valutare la reale efficacia di Zopfli, ma intanto mi seguo il Changelog che lascia ben sperare in quanto i ragazzi ci stanno lavorando costantemente. Mi aspetto grandi cose.
