⏱️ Lectura: 10 min
BZip3 acaba de demostrar que se puede comprimir el mismo archivo hasta un 84% más chico que con BZip2, sin tocar una sola línea del contenido original. El proyecto de código abierto, publicado en GitHub por el desarrollador iczelia, se presenta como el sucesor espiritual de BZip2: mismo objetivo general, pero con un motor completamente distinto por dentro.
📑 En este artículo
En un benchmark público con el código fuente completo de Perl 5, bzip3 pasó de un archivo de 3,44 GB comprimido con BZip2 a uno de apenas 546 MB. Es la clase de mejora que importa cuando administrás backups, repositorios de código o pipelines de CI que mueven gigabytes de texto todos los días.
TL;DR
- BZip3 es un compresor open source que se presenta como sucesor espiritual de BZip2, publicado en GitHub por iczelia.
- Con Perl 5 completo, BZip3 -b511 comprimió el archivo a 546.456.978 bytes frente a 3.441.163.911 bytes de BZip2.
- Eso equivale a un archivo casi 84% más chico que el de BZip2 con el mismo contenido de prueba.
- LZMA (xz -9) llegó a 2.056.645.240 bytes: mejor que BZip2, pero muy por detrás de BZip3 -b511.
- BZip3 descomprimió el corpus en 4min06s frente a 9min22s de BZip2 y 4min40s de xz, en un disco HDD.
- Combinado con lrzip para deduplicación de largo alcance, BZip3 bajó el resultado final a apenas 60.672.608 bytes.
- El motor usa BWT vía arrays de sufijos, RLE+LZ77 con modelado PPM y un codificador de entropía por mezcla de contexto.
- El repositorio acumula 1.400 estrellas y 61 forks en GitHub, y ya se instala con brew install bzip3 en macOS.
Qué pasó
El repositorio iczelia/bzip3 lleva tiempo publicado en GitHub, pero volvió a circular en comunidades de desarrolladores por sus números de compresión frente a herramientas clásicas como BZip2, LZMA (xz) y Zstandard. El autor documentó un benchmark propio: descargó cada versión de Perl 5 publicada en CPAN, las descomprimió y empaquetó todo en un único archivo .tar para comparar compresores en igualdad de condiciones.
El resultado con BZip2 fue un archivo de 3.441.163.911 bytes. Con LZMA (xz -9) bajó a 2.056.645.240 bytes. Pero bzip3, corriendo con bloques de 511 MiB, lo redujo a 546.456.978 bytes: menos de un sexto del tamaño que ocupaba con BZip2.
Contexto e historia
BZip2 nació en 1996 y todavía se usa en distribuciones Linux, en el formato .tar.bz2 y en herramientas de compresión de vieja guardia. Su compresor se basa en la transformada de Burrows-Wheeler combinada con codificación Huffman, un diseño eficaz para su época pero que no aprovecha las CPUs multinúcleo ni los avances en modelado de entropía de las últimas dos décadas. Podés repasar su historia completa en la página de BZip2 en Wikipedia.
bzip3 toma la misma idea central (BWT más agrupar símbolos similares antes de comprimir) pero cambia casi todo el resto del pipeline. En vez de Huffman, usa un codificador de entropía con mezcla de contexto de orden 0. En vez de un solo paso de reordenamiento, agrega una etapa de RLE combinada con emparejamiento de cadenas estilo LZ77 y modelado estilo PPM antes de entrar al codificador final.
El proyecto declara soporte probado en diez arquitecturas distintas: x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc y s390x. Esa cobertura es poco común para un proyecto de compresión relativamente joven y sugiere que ya corrió en hardware embebido, servidores ARM y máquinas legacy por igual.
Detalles técnicos de BZip3 y su rendimiento
La tabla siguiente resume el benchmark contra sus principales alternativas, comprimiendo el mismo archivo .tar con el historial completo de Perl 5:
| Método | Tamaño comprimido | Tiempo total de compresión |
|---|---|---|
| LZMA (xz -9, 16 hilos) | 2.056.645.240 bytes | 12min 09s |
| BZip2 -9 | 3.441.163.911 bytes | 17min 16s |
| BZip3 -b 256 (12 hilos) | 1.001.957.587 bytes | 7min 10s |
| BZip3 -b 511 (4 hilos) | 546.456.978 bytes | 7min 08s |
| Zstandard -16 (12 hilos) | 3.076.143.660 bytes | 6min 35s |
Con bloques de apenas 256 MiB, bzip3 ya comprime a menos de un tercio del tamaño de BZip2, en la mitad de tiempo. Subir el bloque a 511 MiB reduce el tamaño final casi a la sexta parte del de BZip2, aunque exige más memoria: el proceso con -b 256 -j 12 llegó a usar 18.301 MiB de RAM durante la compresión, y con -b 511 -j 4 el pico bajó a 12.178 MiB.
En descompresión, medida aparte sobre un disco mecánico WD Blue, bzip3 en modo paralelo tardó 4min 06s: más rápido que BZip2 (9min 22s) y que LZMA (4min 40s), y casi a la par de Zstandard (3min 51s).
El pipeline interno de bzip3 encadena tres etapas antes de escribir el archivo final:
flowchart TD
A["Datos de entrada"] --> B["BWT via arrays de sufijos"]
B --> C["RLE + LZ77 con modelado PPM"]
C --> D["Codificador de entropia (mezcla de contexto orden 0)"]
D --> E["Archivo .bz3"]El rendimiento real depende mucho del compilador. Según la documentación del repositorio oficial de bzip3, los builds de Linux x64 compilados con Clang 13 alcanzan hasta 17 MiB/s de compresión y 23 MiB/s de descompresión por hilo. Los builds de Windows y de 32 bits suelen rendir bastante menos.
💡 Tip: el flag-jcontrola cuántos hilos usa bzip3. Con bloques grandes (-b 511) necesitás menos hilos para saturar la CPU porque cada bloque ya es una unidad de trabajo grande; con bloques chicos conviene subir-jpara paralelizar más.
Cómo empezar con BZip3
Instalar bzip3 no requiere pasos raros: es un proyecto con autotools y CMake, y ya llegó a los gestores de paquetes más comunes.
# Linux (compilar desde un clon del repositorio con git)
$ ./bootstrap.sh
$ ./configure
$ make
$ sudo make install
# macOS (via Homebrew)
$ brew install bzip3
# Windows (via CMake, con Visual Studio o MinGW/MSYS2 instalado)
> cmake -B build -S . -DCMAKE_BUILD_TYPE=Release
> cmake --build build --config ReleaseEn Linux, si instalaste desde un paquete de código fuente (no un git clone), podés saltarte el paso de ./bootstrap.sh. En Windows y en builds de 32 bits, el propio proyecto advierte que el rendimiento suele ser considerablemente menor que en Linux x64.
Una vez instalado, comprimir y descomprimir un archivo real se ve así:
# Comprimir con bloques de 256 MiB y 12 hilos en paralelo
$ bzip3 -e -b 256 -j 12 backup.tar
# Descomprimir el resultado
$ bunzip3 backup.tar.bz3El flag -e fuerza el modo de compresión explícito, -b fija el tamaño de bloque en MiB y -j el número de hilos. Para confirmar que la instalación quedó bien, corré bzip3 --help: tiene que listar esas opciones junto con -d para descompresión manual.
Impacto y análisis
El caso de uso donde bzip3 más se nota es texto y código fuente: repositorios git empaquetados, logs, datasets en CSV o JSON, y árboles de código como el benchmark de Perl 5. El propio README lo dice sin vueltas: bzip3, igual que su antecesor, “excels at compressing text or code”. Para binarios ya comprimidos (imágenes JPEG, videos, archivos ZIP anidados) la ventaja se reduce, porque ahí ningún compresor de propósito general saca mucho jugo.
El combo con lrzip es interesante para archivos gigantes con mucha redundancia de largo alcance: lrzip hace la deduplicación entre partes distantes del archivo, y bzip3 comprime lo que queda. En el benchmark, esa combinación bajó el .tar.lrz de Perl 5 a 60.672.608 bytes, contra 64.774.202 bytes de lrzip+lzma y 75.685.065 bytes de lrzip+bzip2.
⚠️ Ojo: el propio proyecto advierte que ningún compresor puede garantizar al 100% que un archivo comprimido se pueda recuperar siempre. Antes de usar bzip3 para backups críticos, probá el ciclo completo de comprimir y descomprimir con datos de prueba y verificá el resultado.
La contrapartida de bzip3 es la memoria. Bloques grandes implican mantener varios cientos de megabytes por hilo activo en RAM durante la compresión, algo que Zstandard evita por diseño (687 MiB de pico en el mismo benchmark, contra más de 12 GB de bzip3 con bloques grandes). Para servidores con poca RAM o contenedores con límites estrictos, bzip3 con bloques chicos (-b 256 o menos) es la opción más razonable.
Qué sigue
El repositorio sigue activo, con 456 commits acumulados y soporte oficial ya empaquetado para macOS vía Homebrew. El README remite a comparativas adicionales contra Turbo-Range-Coder y BSC dentro del propio repositorio, lo que sugiere que el proyecto se sigue midiendo activamente contra el estado del arte en compresión sin pérdida.
Para equipos que hoy dependen de .tar.bz2 en pipelines de CI o de distribución de paquetes, el próximo paso lógico es correr el propio dataset (no el de Perl 5) contra bzip3 con distintos tamaños de bloque, y comparar tamaño final, tiempo de compresión y memoria pico antes de migrar cualquier proceso de producción.
📖 Resumen en Telegram: Ver resumen
Probalo vos: cloná el repositorio de bzip3 en GitHub y corré bzip3 -e -b 256 -j 4 sobre tu propio repositorio de código para comparar el tamaño final contra el .tar.gz que ya usás.
Preguntas frecuentes
¿BZip3 es compatible con archivos .bz2 de BZip2?
No. bzip3 usa un formato de contenedor propio (extensión .bz3) y un pipeline de compresión distinto. Para abrir un .bz2 necesitás bzip2 o una herramienta que lo soporte explícitamente; bzip3 no lee ese formato.
¿Cuánta memoria necesita BZip3 para comprimir?
Depende del tamaño de bloque. En el benchmark de Perl 5, correr bzip3 con -b 256 -j 12 llegó a usar 18.301 MiB de RAM; con -b 511 -j 4 el pico bajó a 12.178 MiB. Bloques más chicos consumen bastante menos memoria.
¿BZip3 corre en Windows?
Sí, mediante CMake con Visual Studio o MinGW/MSYS2, aunque el propio proyecto advierte que los builds de Windows y de 32 bits suelen rendir considerablemente menos que Linux x64 con Clang.
¿En qué arquitecturas está probado BZip3?
El README lista x86, x86_64, armv6, armv7, aarch64, ppc64le, mips, mips64, sparc y s390x como plataformas ya verificadas.
¿BZip3 sirve para comprimir imágenes o video?
No es su punto fuerte. bzip3 está optimizado para texto y código fuente; archivos binarios ya comprimidos (JPEG, MP4, ZIP) no se benefician tanto de su pipeline de BWT y modelado de contexto.
¿Es seguro usar BZip3 para backups sin probarlo antes?
El propio proyecto no lo recomienda: el disclaimer del README pide no comprimir datos críticos sin aceptar la posibilidad, aunque sea baja, de que el archivo no se pueda recuperar. Probar el ciclo completo de comprimir y descomprimir antes de confiar en él para producción es la práctica sensata.
Referencias
- iczelia/bzip3 en GitHub: repositorio oficial, código fuente y benchmarks completos.
- Archivo de versiones de Perl 5 en CPAN: el dataset usado en el benchmark de compresión.
- Transformada de Burrows-Wheeler en Wikipedia: contexto sobre el algoritmo que comparten BZip2 y BZip3.
- BZip2 en Wikipedia: historia y contexto del compresor predecesor.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Sebastian Kanczok en Unsplash
0 Comentarios