Certains diront que je débarque, mais le fait est qu’il y a eu une récente actualité autour de ce format relativement récent de compression sans perte, car il commence à être utilisé par défaut sur Arch Linux, et par conséquent, Manjaro. On s’est déjà intéressé à la compression sous plusieurs formes par le passé, ça fait longtemps, voyons pourquoi ce format gagne en popularité.
C’est en effet suite à une note de mise à jour du 20 janvier dernier que j’ai entendu réellement parler de zstd :
Upstream notice
:
Arch updated their default compression to zstd 18. We adopted to the same standard. More and more packages will have the zst extension from now on.
Bon, OK, un nouveau format que je ne connaissais pas. C’est pas si choquant, ma veille n’est pas spécialement orientée sur ces sujets, donc on va un peu s’intéresser à ce nouveau venu qui semble avoir beaucoup de succès auprès de différentes distributions Linux comme on va le voir.
Here comes a new challenger
Zstandard, parce que c’est son vrai nom, est tout récent dans l’univers des algorithmes de compression sans perte, car il n’est développé que depuis 2015. Enfin presque, car un de ses principes fondamentaux remonte à… 1977. L’utilisation d’un dictionnaire n’est donc pas nouveau pour la compression, il est même d’ailleurs au cœur du format LZMA qui a gagné en popularité grâce à un outil que vous devez connaître, 7-zip. Autant dire qu’on connaît bien les maths derrière ça; pas moi personnellement hein, je suis pas encore assez bon, mais y’a des furieux qui maîtrisent bien le sujet, et si vous voulez en savoir plus, Wikipedia est votre ami.
Mais alors quel est l’attrait de ce petit nouveau pas si nouveau d’un point de vue conceptuel ? Pourquoi est-il soutenu par Facebook ? Eh bien, sa grande promesse n’est pas lié à sa performance de compression, mais sa rapidité. Rapidité à la fois pour la compression mais aussi la décompression, peut-être encore plus pour la décompression d’ailleurs, car ses performances varient peu quelque soit le niveau de compression choisi au départ. Quant au niveau de compression, il est censé être comparable à gzip, tout en étant plus rapide que celui-ci.
Et si on testait nous-même ?
Pour vérifier ça, j’ai fait deux petits tests afin de mesurer cette promesse. Le premier est sur un unique fichier WAV, qui ne devrait pas donner de très bons résultats sur le taux de compression, l’autre sur un dossier composite à savoir une copie du blog, donc un mix entre fichiers textes et images, plus intéressant. Ce dossier sera « concaténé » dans un fichier tar, même si zstd est capable d’itérer sur un dossier en mode récursif, ce que ne savent pas nécessairement faire ses cousins.
Pour chaque test, j’ai fait une copie distincte du fichier d’origine pour limiter les impacts du cache noyau par une lecture répétée. J’utilise time pour mesurer le temps de traitement, compression et décompression, et les paramètres par défaut pour chaque commande. Voilà, les conditions sont posées, passons aux résultats.
Pas étonnant qu’il soit populaire
À voir les chiffres, on comprend un peu mieux le choix d’abord d’Ubuntu, puis d’Arch Linux et donc de Manjaro, de basculer sur ce format plutôt qu’un autre. Arch Linux utilisait xz jusqu’ici, et on voit que si ça fonctionne bien d’un point de vue stockage, et donc économie en transfert de données via Internet, le coût en termes de performances à la fois en compression et décompression ne vaut finalement pas la chandelle. Autant consommer un peu plus d’espace disque, un peu plus de réseau, pour finalement gagner en temps de travail aussi bien à la création qu’à l’installation. Ça serait intéressant de comparer le coût énergétique entre le transfert additionnel sur le réseau, et les calculs nécessaires pour générer les archives, mais c’est un peu compliqué et hors scope ici.
Reste que le format est soutenu par Facebook, et naturellement ça fait un peu peur, mais vu la finalité, il y a peu à craindre quant à sa pérennité, contrairement au support PHP d’HHVM qui a pris fin il y a un an. Si l’utilitaire zstd n’est pas dispo nativement sur votre système, vous pouvez vous tourner vers le dépôt Github qui regorge d’informations à son sujet, avec d’autres chiffres de performances, effectués sur une machine hors de portée du commun des mortels.
En tout cas, je pense que c’est une bonne décision d’y être passé sur Arch Linux, et pour avoir souffert avec quelques créations de paquets AUR qui prennent beaucoup de temps même avec xz en multiithread, j’espère que la plupart des recettes basculeront sur ce format rapidement.