Zstd : c’est quoi ce format de compression ?

Cet article a été publié il y a 4 ans 1 mois 19 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

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.

Fichier WAV

Eh bien le moins qu’on puisse dire, c’est que c’est effectivement très rapide. Et quid de la taille ?

On voit que le xz est largement au dessus des deux autres concurrents, mais le prix en temps de compression est très élevé. Ici, on voit que le zstd est moins performant par défaut que gzip, mais comme je l’ai dit, ce n’est pas nécessairement représentatif car le format de fichier ne se prête pas vraiment à l’objectif, de ce côté les formats liés à la compression audio ont de meilleurs résultats. Et le temps de compression est vingt fois plus court, donc facile d’être séduit par le petit dernier de la bande.

Ça, c’est pour la compression, voyons donc les résultats de décompression :

Une fois encore, on voit que xz est loin derrière en termes de rapidité, alors que zstd caracole en tête.  Il semble donc tenir une grande partie de ses promesses.

Dossier du blog

Passons à quelque chose de plus représentatif des pratiques d’archivage. Déjà ce qui est marrant, c’est la différence entre le dossier d’origine, et le fichier tar utilisé pour le test :

Il y a donc près de 30Mo de perdus en petits fichiers qui prennent plus de place dans le système de fichiers que leur taille réelle. Mais on est pas là pour en faire l’analyse, revenons à nos moutons. Même motif que précédemment, copie du fichier tar pour chaque algorithme, voilà le résultat de compression :

Euh, ok, là encore, zstd est loin devant en termes de rapidité, xz est hors concours de par sa lenteur, et ça donne quoi sur les tailles résultantes ?

Ah ! Effectivement, cette fois le résultat est proche de gzip, mais donc pour un traitement huit fois plus rapide. Et ça en compression. Et en décompression ?

Bon, les temps de décompression sont un peu moins impressionnants, mais tout de même, près de trois fois plus rapides. J’arrête là les manipulations, je pense qu’on a nos réponses.

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.