2010-03-26 15 views
5

Estoy tratando de encontrar un equilibrio entre el rendimiento y el grado de compresión cuando gzip una respuesta de Java webapp.Estrategias de Java Deflater - DEFAULT_STRATEGY, FILTERED y HUFFMAN_ONLY

Al mirar la clase Deflater, puedo establecer un nivel y una estrategia. Los niveles son auto explicativos: BEST_SPEED a BEST_COMPRESSION.

no estoy seguro en relación con las estrategias - DEFAULT_STRATEGY, FILTERED y HUFFMAN_ONLY

puedo tener un cierto sentido de la Javadoc pero me preguntaba si alguien había utilizado una estrategia específica en sus aplicaciones y si usted vio ninguna diferencia en términos de rendimiento/grado de compresión.

Respuesta

14

Las opciones de estrategia mencionadas en Java Deflater se originaron en la implementación zlib (C) de ZLIB y (RFC 1950) y DEFLATE (1951), creo. Están presentes en prácticamente todas las bibliotecas de compresión que implementan DEFLATE.

Para entender lo que significan, necesita saber un poco acerca de DEFLATE. El algoritmo de compresión combina la codificación LZ77 y Huffman. Los conceptos básicos son:

  • La compresión LZ77 funciona buscando secuencias de datos que se repiten. Las implementaciones suelen utilizar una "ventana deslizante" de entre 1k y 32k, para realizar un seguimiento de los datos que se utilizaron anteriormente. Para cualquier repetición en los datos originales, en lugar de insertar los datos repetidos en la salida, la compresión LZ77 inserta una "referencia retrospectiva". Imagine la referencia que dice "aquí, inserte los mismos datos que vio hace 8293 bytes, para 17 bytes". La retro-referencia está codificada como este par de números: una longitud, en este caso 17, y una distancia (o desplazamiento), en este caso, 8293.

  • La codificación Huffman sustituye los códigos por los datos reales. Cuando los datos dicen X, el código de Huffman dice Y. Esto obviamente ayuda a la compresión solo si el sustituto es más corto que el original. (Un contraejemplo está en la película Jim Carrey Yes Man, cuando Norm usa "Car" para un nombre corto para Carl. Carl señala que Carl ya es bastante corto.) El algoritmo de codificación de Huffman hace un análisis de frecuencia y usa los sustitutos más cortos para las secuencias de datos que ocurren con mayor frecuencia.


desinflado combina estos, por lo que uno puede usar códigos de Huffman en LZ77 copias de árbitros. Las opciones de estrategia en varios compresores DEFLATE/ZLIB solo le dicen a la biblioteca cuánto debe pesar Huffman versus LZ77.

  • FILTERED por lo general significa que los partidos LZ77 se detuvieron en una longitud de 5. Así que cuando la documentación dice

    Uso (filtrado) para los datos producidos por un filtro (o predictor), ... Los datos filtrados consisten principalmente en valores pequeños con una distribución algo aleatoria.

    (de the zlib man page)
    ... mi lectura del código dice que lo hace LZ77 juego, pero sólo hasta las secuencias de 5 o menos bytes. Eso es lo que significa el doc por "valores pequeños", supongo.Pero el número 5 no se menciona en el documento, por lo que no hay garantía de que el número no cambie de rev a rev, o de una implementación de ZLIB/DEFLATE a otra (como la versión C y la versión Java).

  • HUFFMAN_ONLY dice, solo haga los códigos de sustitución en función del análisis de frecuencia. HUFFMAN_ONLY es muy muy rápido, pero no muy efectivo en compresión para la mayoría de los datos. A menos que tenga un rango muy pequeño de valores de bytes (por ejemplo, si los bytes en su flujo de datos real toman uno de solo 20 de los posibles 255 valores), o tiene requisitos extremos para la velocidad de compresión a expensas del tamaño, HUFFMAN_ONLY no será Lo que quieras.

  • DEFAULT combina los dos en la forma en que los autores esperaban que fuera más efectivo para la mayoría de las aplicaciones.


Por lo que yo sé, dentro de DESINFLE no hay manera de hacerlo solamente LZ77. No hay una estrategia LZ77_ONLY. Pero, por supuesto, podrías construir o adquirir tu propio codificador LZ77 y ese sería "LZ77 solamente".


Tenga en cuenta que la estrategia nunca afecta la corrección de la compresión; solo afecta su funcionamiento y el rendimiento del mismo, ya sea en velocidad o tamaño.


Existen otras formas de ajustar el compresor. Una es establecer el tamaño de la ventana deslizante LZ77. En la biblioteca C, esto se especifica con la opción "Bits de ventana". Si entiendes LZ77, entonces sabes que una ventana más pequeña significa menos búsqueda hacia atrás, lo que significa una compresión más rápida, a expensas de perder algunas coincidencias. Esta suele ser la perilla más efectiva para girar cuando se comprime.


La conclusión es que, para el caso del 80%, no importa que modificar la estrategia. Puede que te interese jugar con las ventanas, solo para ver qué pasa. Pero solo hazlo cuando hayas hecho todo lo demás que necesitas hacer en tu aplicación.


referencia:
How DEFLATE works, by Antaeus Feldspar

Cuestiones relacionadas