bzip3 est présenté comme le successeur spirituel de bzip2l'outil de compression ouvert qui accompagne les serveurs et distributions Linux depuis des années. Développé par Kamila Szewczyk et publié sur GitHub, promet des taux de compression nettement plus élevés et des temps de traitement plus courts que son prédécesseur, en particulier lorsque le matériel à compresser est du texte ou du code source.
Il ne s'agit pas d'un fork, mais d'une réécriture complète. bzip3 combine un encodeur entropique mélangeant un contexte d'ordre 0, une transformation de Burrows-Wheeler accélérée à l'aide de tableaux de suffixes (via le libsaispar Ilya Grebnov) et une passe RLE avec prédiction Lempel-Ziv plus, une technique inspirée de la modélisation de contexte LZ77 et PPM. Cette combinaison vous permet de tirer parti des données répétitives, ce qui est courant dans les référentiels de code, les sauvegardes de bases de données et les journaux archivés.
Les références par rapport à xz, zstd et bzip2 sont remarquables
Szewczyk a publié son propre benchmark de compression 262 archives tar de toutes les versions de Perl 5 dans un seul fichier. Dans son mode le plus agressif (-b 511), bzip3 réduit ce corpus à 546 456 978 octetspar rapport aux 3 441 163 911 octets de bzip2 et aux 2 056 645 240 octets de LZMA (xz).
La différence est 6,3 fois par rapport à bzip2 et 3,8 fois par rapport à Zstandard, qui reste à 3 076 143 660 octets pour le même fichier. Avec le temps, bzip3 termine la compression en 7 minutes et 8 secondescontre 12 minutes et 9 secondes pour xz. La décompression gagne également : 4 minutes et 6 secondes contre 9 minutes et 22 secondes pour bzip2, et près de 3 minutes et 51 secondes pour zstd. Les performances dépendent du compilateur : les versions pour Linux x64 avec clang13 sont d'environ 17 Mio/s de compression et 23 Mio/s de décompression par thread, tandis que Windows ou les binaires 32 bits sont à la traîne.
Où il est judicieux d'utiliser bzip3 aujourd'hui et ses risques
L'ajustement immédiat n'implique pas le remplacement de gzip dans un CDN ou de zstd dans un bus d'événements à faible latence. Son terrain naturel est constitué de fichiers de longue durée : instantanés de bases de données, distributions d'ensembles de données, sauvegardes à froid et, en général, tout référentiel dominé par du texte ou du code source.
Combiné avec lrzipqui assure une mise en miroir longue portée avant compression, le fichier Perl utilisé comme référence tombe à 60 072 608 octets, en dessous des 64 774 202 octets de lrzip avec lzma et des 75 685 065 octets de lrzip avec bzip2.
Il convient de ne pas perdre de vue ses limites : le format est incompatible avec bzip2 (un fichier .bz2 ne peut pas être ouvert avec bunzip3, ni l'inverse), la valeur maximale du paramètre block (-b 511) nécessite des pics de mémoire RAM proches de 12 Go, ce qui est délicat dans des environnements d'intégration continue avec des quotas serrés, et l'écosystème qui l'entoure est encore jeune, ce qui, comme on pouvait s'y attendre, limite son intégration en série dans les pipelines les plus courants pour l'instant.
Installation, licence et notice à savoir
Pour l'essayer, vous pouvez compiler le code source avec les commandes habituelles (git clone, bootstrap.sh, configure et make) ou l'installer directement via Homebrew sur macOS. Le référentiel principal accumule 1 300 étoiles19 watchers et 61 forks, et il apparaît déjà packagé dans plusieurs distributions Linux.
Le projet est distribué sous licence LGPLv3: Toute modification apportée à la bibliothèque bzip3/libbz3 elle-même doit être publiée sous cette même licence, mais la liaison dynamique à partir d'un logiciel propriétaire est autorisée sans nécessiter la publication de code supplémentaire. Malgré tout, Szewczyk inclut dans le README un avertissement inhabituel et très direct : ne compressez pas les données avec ce programme à moins que vous ne soyez prêt à accepter la possibilité, même minime, qu'elles ne puissent pas être récupérées. Il ne s’agit pas d’une déclaration légale d’engagement ; c'est une recommandation explicite de conserver une deuxième copie avec xz ou zstd pendant que le projet termine sa maturation.
FAQ bzip3 Non. Le format est incompatible : un fichier compressé avec bzip3 ne peut pas être ouvert avec les outils bzip2, ni l'inverse.
Avec le paramètre block à sa valeur maximale (-b 511), le benchmark de l'auteur rapporte des pics de mémoire proches de 12 Go lors de la compression.
L'auteur elle-même prévient qu'il y a une petite chance que les données compressées avec bzip3 ne soient pas récupérables, elle recommande donc de conserver une deuxième copie avec xz ou zstd pendant que le projet mûrit.
Bzip3 est-il un remplacement immédiat de bzip2 ?
De quelle quantité de RAM bzip3 a-t-il besoin dans son mode le plus agressif ?
Bzip3 peut-il être utilisé pour les données critiques en production ?