2010-03-26 25 views
5

J'essaie de trouver un équilibre entre les performances et le degré de compression lors du gzippage d'une réponse webapp Java.Stratégies Java Deflater - DEFAULT_STRATEGY, FILTERED et HUFFMAN_ONLY

En regardant la classe Deflater, je peux définir un niveau et une stratégie. Les niveaux sont explicites - BEST_SPEED à BEST_COMPRESSION.

Je ne suis pas sûr en ce qui concerne les stratégies - DEFAULT_STRATEGY, FILTERED et HUFFMAN_ONLY

Je peux faire un certain sens de la Javadoc mais je me demandais si quelqu'un avait utilisé une stratégie spécifique dans leurs applications et si vous avez vu une différence en termes de performance/degré de compression.

Répondre

14

Les options stratégiques mentionnées dans Java Deflater origine dans la zlib (C) et la mise en œuvre de ZLIB (RFC 1950) et DEFLATE (1951), je crois. Ils sont présents dans pratiquement toutes les bibliothèques de compression qui implémentent DEFLATE.

Pour comprendre ce qu'ils signifient, vous devez en savoir un peu plus sur DEFLATE. L'algorithme de compression combine le codage LZ77 et Huffman. Les bases sont:

  • La compression LZ77 fonctionne en recherchant des séquences de données répétées. Les implémentations utilisent généralement une "fenêtre glissante" comprise entre 1k et 32k, pour garder une trace des données antérieures. Pour toutes les répétitions dans les données d'origine, au lieu d'insérer les données répétées dans la sortie, la compression LZ77 insère une "référence arrière". Imaginez la référence arrière disant "ici, insérez les mêmes données que vous avez vues il y a 8293 octets, pour 17 octets". L'arrière-ref est codé en tant que cette paire de nombres: une longueur - dans ce cas 17 - et d'une distance (ou offset) - dans ce cas, 8293.

  • codage de Huffman codes des substituts pour les données réelles. Quand les données indiquent X, le code de Huffman dit Y. Cela aide évidemment la compression seulement si le substitut est plus court que l'original. (un contre-exemple est dans le film Jim Carrey Yes Man, quand Norm utilise "Car" pour un nom court pour Carl. Carl souligne que Carl est déjà assez court.) L'algorithme de codage de Huffman fait une analyse fréquentielle, et utilise les plus brefs substituts pour les séquences de données qui surviennent le plus souvent.


Deflate combine ceux-ci, de sorte que l'on peut utiliser des codes de Huffman sur LZ77 back-refs. Les options de stratégie sur divers compresseurs DEFLATE/ZLIB indiquent simplement à la bibliothèque à quel point Huffman et LZ77 doivent être pondérés.

  • FILTERED signifie généralement les matchs LZ77 sont arrêtés à une longueur de 5. Ainsi, lorsque la documentation dit

    Utilisation (Filtrés) pour les données produites par un filtre (ou prédicteur), ... Les données filtrées consistent principalement en de petites valeurs avec une distribution quelque peu aléatoire.

    (de the zlib man page)
    ... ma lecture du code dit qu'il ne correspondant LZ77, mais seulement jusqu'à des séquences de 5 octets ou moins. C'est ce que le document veut dire par "petites valeurs", je suppose.Mais le nombre 5 n'est pas mentionné dans le document, donc il n'y a aucune garantie que le nombre ne sera pas changé de rev à rev, ou d'une implémentation de ZLIB/DEFLATE à une autre (comme la version C et la version Java).

  • HUFFMAN_ONLY indique seulement les codes de substitution basés sur l'analyse de fréquence. HUFFMAN_ONLY est très très rapide, mais pas très efficace en compression pour la plupart des données. Sauf si vous avez une très petite plage de valeurs d'octets (par exemple, si les octets de votre flux de données réel prennent l'une des 20 valeurs possibles), ou si vous avez des besoins extrêmes de compression en termes de taille, HUFFMAN_ONLY ne sera pas ce que tu veux.

  • DEFAULT combine les deux de la manière dont les auteurs pensaient que ce serait le plus efficace pour la plupart des applications.


Pour autant que je sache, dans les DEFLATE il n'y a pas moyen de le faire que LZ77. Il n'y a pas de stratégie LZ77_ONLY. Mais bien sûr, vous pourriez construire ou acquérir votre propre encodeur LZ77 et ce serait "LZ77 seulement". Gardez à l'esprit que la stratégie n'a jamais d'incidence sur l'exactitude de la compression;


il n'en affecte que le fonctionnement et la performance, soit en vitesse, soit en taille.


Il existe d'autres façons de régler le compresseur. L'une consiste à définir la taille de la fenêtre coulissante LZ77. Dans la bibliothèque C, ceci est spécifié avec une option "Bits de fenêtre". Si vous comprenez LZ77, alors vous savez qu'une fenêtre plus petite signifie moins de recherche, ce qui signifie une compression plus rapide, au détriment de certaines correspondances. C'est souvent le bouton le plus efficace pour tourner lors de la compression.


La ligne de fond est que, pour le cas de 80%, vous ne vous souciez pas de modifier la stratégie. Vous pourriez être intéressé par jouer avec des morceaux de fenêtre, juste pour voir ce qui se passe. Mais faites-le seulement quand vous avez fait tout ce que vous avez à faire dans votre application.


Référence:
How DEFLATE works, by Antaeus Feldspar