Login Barrapunto
Comparación entre diferentes algoritmos de compresión en Linux
John Goerzen publica en su blog una comparativa entre diferentes algoritmos de compresión bastante populares en Linux (Gzip, Bzip2 y LZMA), profundizando en un análisis previo hecho por Wim Heirman (que analiza más formatos diferentes, y que se basa a su vez en otro test anterior, realizado por Johan De Bock), llegando a la conclusión de que Gzip sigue siendo el ganador en términos de eficiencia tiempo/compresión, y que Bzip2 es ampliamente superado por LZMA (consigue mejor compresión en menos tiempo). Aunque Bzip2 cuenta como característica positiva que reinicia todos sus contadores cada 900K (aumentando ligeramente la seguridad por ello), Gzip parece ser mejor opción cuando el tiempo es un factor importante, y LZMA cuando el espacio ocupado es prioritario.
Actualización: 02/18 09:13 GMT por inniyah: John Goerzen ha publicado la segunda parte de su análisis.
Actualización: 02/18 09:13 GMT por inniyah: John Goerzen ha publicado la segunda parte de su análisis.
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
Comparación entre diferentes algoritmos de compresión en Linux
|
Log in/Crear cuenta
| Top
| 46 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

Compresión extrema en BP
(Puntos:3, Informativo)( http://yapw.blogspot.com/ | Última bitácora: Jueves, 11 Noviembre de 2010, 09:53h )
Y después de comentar voy a leer el los
Y tú ¿Ya usas tu bitácora [barrapunto.com] para hablar de las noticias que te interesan?
Fichero sólido
(Puntos:1)LZ77 vs LZMA
(Puntos:4, Informativo)( http://www.voluntariado.net/ | Última bitácora: Martes, 07 Diciembre de 2010, 19:25h )
En lo que respecta a la compresión, a menudo, más que cambiar de algoritmo de compresión, lo que suele dar mejores resultado es *ayudar* al algoritmo para mejorar los ratios (e.g. organizar los datos para que la redundancia pueda ser identificada por localidad por el compresor, etc.). Tampoco es necesario comprimir todo el rato con un diccionario del mismo tamaño, pues si "detectas" que la señal tiene mucho desorden, es recomendable ajustar el tamaño de diccionario a la baja, evitar que el diccionario te haga salir de la caché de segundo nivel, etc.
Añadiría que el "archivo sólido" es más eficiente que el "tarball típico", excepto si se usa algún truco del almendruco para ordenarlo (2 [barrapunto.com]).
P.D. Con dos autocitas entro en la "champions league" de la cancamusa XD
Si quieres benchmarks...
(Puntos:3, Informativo)El recurso con mayor información que he encontrado sobre compresión sin pérdidas (en tema comparativas).
Nada, nada, nada...
(Puntos:3, Divertido)( http://kernel.org/ | Última bitácora: Jueves, 23 Septiembre de 2010, 19:27h )
Re:Nada, nada, nada...
(Puntos:4, Divertido)( http://netpatia.blogspot.com/ )
Aplicaciones Android [blogspot.com]
Re:La gente no puede estar equivocada
(Puntos:2)Re:La gente no puede estar equivocada
(Puntos:2)( http://www.miriamruiz.es/ )
Re:La gente no puede estar equivocada
(Puntos:2, Divertido)Re:Duda
(Puntos:3, Informativo)( http://www.miriamruiz.es/ )
On the other hand, when you're doing backups, the calculation is different. Your storage media costs money, but so does your CPU. If you have a large photo collection or edit digital video, you may create 50GB of new data in a day. If you use a compression algorithm that's too slow, your backup for one day may not complete before your backup for the next day starts. This is even more significant a problem when you consider enterprises backing up terabytes of data each day.
Re:La gente no puede estar equivocada
(Puntos:3, Inspirado)( http://www.demoncrusher.com/ | Última bitácora: Miércoles, 27 Octubre de 2010, 14:13h )
-------
[es_CL]
Demoncrusher: ThrashMetal [demoncrusher.com]
Re:Duda
(Puntos:3, Inspirado)( http://barrapunto.com/ | Última bitácora: Viernes, 13 Noviembre de 2009, 15:33h )
Salu2
Re:La gente no puede estar equivocada
(Puntos:3, Informativo)( http://www.voluntariado.net/ | Última bitácora: Martes, 07 Diciembre de 2010, 19:25h )
Abraham Lempel y Jacob Ziv: LZ77 [wikipedia.org]
David Huffman: codificación Huffman [wikipedia.org] (usado por Katz para reducir la redundancia del LZ77)
En su momento, lo que sí hizo Katz fue un trabajo excelente de optimización con ensamblador de 8086.
Re:bz2
(Puntos:1, Informativo)Podrías empezar por leer la noticia: dice que gzip es el mejor en la relación compresión/tiempo, y aunque que bzip en mejor compresión, puestos a perder el tiempo es mejor que lo dediques a LZMA, que es mejor aún, y tiene tiempos de descompresión mucho mejores (que es lo que interesa la mayor parte de las veces).
Re:Duda
(Puntos:2)Re:La gente no puede estar equivocada
(Puntos:1, Divertido)Re:La gente no puede estar equivocada
(Puntos:2)( http://www-etsi2.ugr.es/alumnos/mu01/guerraSoftware.html | Última bitácora: Viernes, 03 Diciembre de 2010, 10:41h )
Gdado dice roller [sourceforge.net]
Re:Vaya
(Puntos:2)( http://www-etsi2.ugr.es/alumnos/mu01/guerraSoftware.html | Última bitácora: Viernes, 03 Diciembre de 2010, 10:41h )
Las diferencias entre gzip y bz2 ya las conocía, y es fácil darse cuenta a poco que experimentes, pues las diferencias tanto en velocidad como en tamaño son muy notables.
Yo suelo usar bz2 cuando el espacio es muy importante o cuando se trata de almacenar un fichero. Si tengo que enviar una serie de archivos por red, uso mejor gzip, pues tardas más en comprimirlo y descomprimirlo en bz2 que en transmitir un fichero más grande.
A partir de ahora habrá que acostumbraré a lzma, cuando esté disponible.
Gdado dice roller [sourceforge.net]
Re:Duda
(Puntos:2)( http://www-etsi2.ugr.es/alumnos/mu01/guerraSoftware.html | Última bitácora: Viernes, 03 Diciembre de 2010, 10:41h )
Otra opción es un programa que comprima sus datos.
Por ejemplo, las partidas guardadas del Wesnoth están comprimidas porque son grandes y tienen mucha redundancia, pero más vale que ocupen un poco más y se carguen rápido.
Gdado dice roller [sourceforge.net]
Re:El mas usado
(Puntos:2)( http://www-etsi2.ugr.es/alumnos/mu01/guerraSoftware.html | Última bitácora: Viernes, 03 Diciembre de 2010, 10:41h )
Gdado dice roller [sourceforge.net]