bzip3
bzip3, un compresor moderno inspirado en la transformada de Burrows–Wheeler de bzip2, está llamando la atención por superar a veces a zstd y otros formatos populares en relación de compresión, especialmente en ciertos conjuntos de datos muy repetitivos. Los comentaristas destacan que sus ventajas dependen mucho de los datos y de los parámetros, señalan que algunos benchmarks publicados son engañosos (por ejemplo, tamaños de ventana desajustados y un gran uso de memoria), y apuntan a una fuerte sobrecarga de descompresión en algunas pruebas reales. También hay debate sobre su adopción práctica, dada la sólida compatibilidad del ecosistema de zstd, las decisiones de licencia y nombre de bzip3, y el hecho de que muchos usuarios ahora priorizan una descompresión rápida y de bajo consumo de memoria frente a mejoras marginales en tamaño.
Puntos de referencia y equidad
- Varios comentaristas critican los puntos de referencia oficiales por ser rudimentarios y estar “seleccionados a dedo”.
- Principales preocupaciones:
- bzip3 se prueba con bloques muy grandes (p. ej., 512 MB) mientras que a zstd se le dejan las ventanas pequeñas predeterminadas (~8 MB), lo que penaliza gravemente a zstd en corpus repetitivos como árboles fuente concatenados.
- El uso de memoria no está normalizado (p. ej., casos con ~12–18 GB de RAM para bzip3 frente a <1 GB para zstd).
- Algunas comparaciones omiten competidores fuertes (zstd en pruebas de lrzip).
- Cuando se vuelve a ejecutar zstd con una ventana larga equivalente (
--long), puede comprimir mucho más pequeño y más rápido de lo informado, superando a veces a bzip3 por amplios márgenes.
Rendimiento en el mundo real y dependencia de los datos
- Múltiples pruebas independientes muestran un comportamiento muy dependiente de los datos:
- En algunos archivos, bzip3 supera a
zstd -19en relación de compresión a una velocidad comparable o mejor. - En otros, zstd gana ligeramente en tamaño y de forma decisiva en velocidad.
- En algunos archivos, bzip3 supera a
- Para un árbol del kernel de Linux, se informó que la descompresión de bzip3 era ~145× más lenta que la de zstd multinúcleo, con una compresión ligeramente peor.
- En el corpus de texto enwik9, bzip3 comprimió de forma sustancialmente más pequeña que zstd, pero usó órdenes de magnitud más RAM y tiempo al descomprimir.
Uso de recursos y casos prácticos
- Un tema recurrente: bzip3 puede lograr relaciones de compresión impresionantes, pero la descompresión puede ser extremadamente lenta y consumir mucha memoria, especialmente con bloques enormes.
- Algunos sugieren usarlo solo para escenarios de “comprimir una vez, descomprimir muchas veces” después de ajustar el algoritmo por archivo.
- Otros concluyen que, en pruebas agregadas, no es “terriblemente impresionante” en comparación con alternativas modernas.
Alternativas y ecosistema
- zstd se describe repetidamente como el compresor de propósito general “de referencia” en la actualidad: muy ajustable, descompresión rápida, buenas relaciones de compresión y amplio soporte (sistemas de archivos, bases de datos).
- Las pruebas sobre registros JSONL muestran que bzip3 ofrece la mejor relación de compresión, pero con un tiempo de CPU mucho mayor; zstd es casi tan pequeño como gzip pero muchísimo más rápido que todo lo demás con los valores predeterminados, con margen para ajustar.
Fiabilidad, licencia y nombre
- La fuerte advertencia de que “los datos pueden no ser recuperables” alarma a algunos, pero otros señalan que existen exenciones idénticas en bzip2, xz y licencias típicas de código abierto.
- A algunos no les gusta reutilizar el nombre “bzip3” ni el cambio a LGPL en lugar de la licencia permisiva de bzip2; otros sostienen que tanto el nombre como la licencia son prerrogativa del autor.
Direcciones futuras
- Ideas planteadas: archivos multistream que seleccionen automáticamente algoritmos por región, optimización de parámetros basada en ML/agentes, y verificación formal de la corrección del compresor, aunque esto último se considera muy difícil.