2010-03-26 25 views
5

Sto cercando di trovare un equilibrio tra prestazioni e grado di compressione durante l'estrazione di una risposta webapp Java.Strategie di deflazione Java - DEFAULT_STRATEGY, FILTERED e HUFFMAN_ONLY

Osservando la classe Deflater, posso impostare un livello e una strategia. I livelli sono auto esplicativi - BEST_SPEED a BEST_COMPRESSION.

non sono sicuro per quanto riguarda le strategie - DEFAULT_STRATEGY, FILTERED e HUFFMAN_ONLY

posso fare un certo senso dalla Javadoc ma mi chiedevo se qualcuno avesse usato una strategia specifica nelle loro applicazioni e se avete visto alcuna differenza in termini di prestazioni/grado di compressione.

risposta

14

Le opzioni strategiche menzionate nel Deflater Java hanno avuto origine nell'implementazione zlib (C) di ZLIB e (RFC 1950) e DEFLATE (1951), credo. Sono presenti praticamente in tutte le librerie di compressione che implementano DEFLATE.

Per capire cosa significano, è necessario conoscere un po 'di DEFLATE. L'algoritmo di compressione combina la codifica LZ77 e Huffman. Le basi sono:

  • La compressione di LZ77 funziona rilevando sequenze di dati che vengono ripetute. Le implementazioni in genere utilizzano una "finestra scorrevole" compresa tra 1k e 32k, per tenere traccia dei dati precedenti. Per eventuali ripetizioni nei dati originali, invece di inserire i dati ripetuti nell'output, la compressione LZ77 inserisce un "riferimento all'indietro". Immagina il riferimento posteriore dicendo "qui, inserisci gli stessi dati che hai visto 8293 byte fa, per 17 byte". Il back-ref è codificato come questa coppia di numeri: una lunghezza - in questo caso 17 - e una distanza (o offset) - in questo caso 8293.

  • Codici di sostituzione Huffman per i dati effettivi. Quando i dati dicono X, il codice Huffman dice Y. Questo ovviamente aiuta la compressione solo se il sostituto è più corto dell'originale. (un contro-esempio è nel film Jim Carrey Yes Man, quando Norm usa "Car" per un nome breve per Carl. Carl sottolinea che Carl è già piuttosto corto.) L'algoritmo di codifica Huffman fa un'analisi di frequenza e usa i sostituti più brevi per le sequenze di dati che si verificano più spesso.


Sgonfiare combina questi, in modo che si può usare codici di Huffman su LZ77 back-rif. Le opzioni strategiche su vari compressori DEFLATE/ZLIB indicano semplicemente alla libreria quanto pesare Huffman rispetto a LZ77.

  • FILTERED di solito significa che le partite LZ77 sono fermato a una lunghezza di 5. Così, quando la documentazione dice

    Usa (filtrata) per i dati prodotti da un filtro (o predittore), ... I dati filtrati sono costituiti principalmente da piccoli valori con una distribuzione alquanto casuale.

    (da the zlib man page)
    ... la mia lettura del codice dice che lo fa LZ77 di corrispondenza, ma solo fino a sequenze di 5 o meno byte. Questo è ciò che il doc intende per "piccoli valori", immagino.Ma il numero 5 non è menzionato nel documento, quindi non c'è garanzia che il numero non cambierà da rev a rev o da un'implementazione di ZLIB/DEFLATE a un'altra (come la versione C e la versione Java).

  • HUFFMAN_ONLY dice, solo fare i codici di sostituzione in base all'analisi di frequenza. HUFFMAN_ONLY è molto molto veloce, ma non molto efficace nella compressione per la maggior parte dei dati. A meno che non si disponga di un intervallo molto piccolo di valori di byte (ad esempio, se i byte nel flusso di dati effettivo prendono uno dei soli 20 dei possibili 255 valori) o se hanno requisiti estremi per la velocità di compressione a spese della dimensione, HUFFMAN_ONLY non sarà ciò che vuoi.

  • DEFAULT combina i due nel modo in cui gli autori si aspettavano che sarebbe stato più efficace per la maggior parte delle applicazioni.


Per quanto ne so, entro DEFLATE non c'è modo di fare solo LZ77. Non esiste una strategia LZ77_ONLY. Ma ovviamente potresti creare o acquisire il tuo codificatore LZ77 e questo sarebbe "solo LZ77".


Tenere presente che la strategia non influisce mai sulla correttezza della compressione; influenza solo e il funzionamento di esso, e le prestazioni di esso, sia in termini di velocità o dimensioni.


Esistono altri modi per regolare il compressore. Uno è quello di impostare la dimensione della finestra scorrevole LZ77. Nella libreria C, questo è specificato con un'opzione "Bit di finestra". Se comprendi LZ77, allora sai che una finestra più piccola significa meno ricerca indietro, il che significa compressione più veloce, a scapito della mancanza di alcune corrispondenze. Questa è spesso la manopola più efficace da girare durante la compressione.


La linea di fondo è che, per il caso dell'80%, non ti interessa modificare la strategia. Potresti essere interessato a giocherellare con i bit della finestra, solo per vedere cosa succede. Ma fallo quando hai fatto tutto il resto che devi fare nella tua app.


di riferimento:
How DEFLATE works, by Antaeus Feldspar

Problemi correlati