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 -19 en 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.
  • 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.