Connexion Premium

[Comparatif Next] 30 algorithmes de compression passés au crible

Le bon, la brute et le truand

[Comparatif Next] 30 algorithmes de compression passés au crible

Illustration : Flock

Ce n’est pas facile de choisir le bon algorithme de compression, cela dépend de vos données et de vos attentes (compression maximum, vitesse de décompression…). Next vous propose un gros comparatif avec 30 algorithmes, plusieurs niveaux de compression et la possibilité d’ajuster les résultats en fonction de vos besoins.

Il y a un peu moins d’un an, à la suite de la sortie d’OpenZL (Meta) et de Turbosqueeze, nous avions comparé les performances de 14 algorithmes de compression. Next remet le couvert avec une trentaine d’algorithmes.

7zip, bzip, lz4, OpenZL, rar, zpaq, zstd… demandez le programme !

Voici la liste : 7zip, 7zip-zz, 7zip-zz-ultra, brotli, BSC, bzip2, bzip3, gzip, libdeflate-gzip, Lizard, lrzip, lz4, lzfse, lzip, lzop, OpenZL, OpenZL-csv, OpenZL (également avec profil pytorch et sao), pixz, plzip, rar, Snappy, TAR, TurboSqueeze, xz (attention, une porte dérobée a été détectée en 2024), zip, zopfli, zpaq, zstd et sa version multithreads zstd-mt. À chaque fois, nous avons pris la dernière version stable disponible.

Lorsque c’était possible, nous avons utilisé trois niveaux de compression : minimum (le plus rapide), maximum (prend bien plus de temps) et enfin moyen (entre les deux). Entre minimum et maximum, le temps nécessaire pour réaliser les tests (252 fichiers pour un total de 2,8 Go environ) est passé de 1h30 environ en mode mini à 16h30 avec la compression max. Plus bas, vous pourrez télécharger l’intégralité de nos résultats.

Le détail des 11 catégories de données

Nous avons passé tout ce petit monde à travers 11 tests, sur différents types de données :

  • CSV : 14 fichiers pour 243 Mo
  • Images : 39 fichiers pour 9,6 Mo (JPG et PNG)
  • ISO : 1 fichier de 347 Mo
  • MP3 : 14 fichiers pour 158 Mo
  • PDF : 122 fichiers pour 199 Mo
  • PyTorch : 2 fichiers pour 143 Mo
  • Silesia : 12 fichiers pour 202 Mo
  • Sao : 1 fichier (celui utilisé par Meta) de 7 Mo
  • Vidéo : 1 fichier de 202 Mo
  • Vrac : 45 fichiers pour 297 Mo (de 1 ko à 135 Mo avec des DLL, des exe, des xml, des log…)
  • enwik9 : 1 fichier de 954 Mo (export au format XML de Wikipédia).

Au total, nous avons donc testé près de 80 combinaisons entre les algorithmes et les trois niveaux de performances, quand c’était possible. Les tests ont été effectués sur un serveur à domicile, avec 24 cœurs Xeon et 64 Go de mémoire à disposition des algorithmes.

Les données sont copiées dans un RAM disque (espace de stockage en mémoire vive pour avoir une très grande passante) avant d’être (dé)compressées fichier par fichier. Trois passes sont faites, avec la moyenne retenue comme résultat.

Nous calculons le ratio de compression des données, le temps nécessaire à la compression et celui pour la décompression (on en profite pour vérifier l’intégrité des données), permettant ainsi de calculer le débit en Mo/s. L’ensemble représente près de 8 000 mesures, que nous vous livrons en intégralité dans une feuille de calcul.

Voici une idée du résultat… pour seulement deux catégories sur 11 de notre comparatif :

Un tableau interactif personnalisable, dont vous êtes le héros

Une telle feuille de calcul n’étant pas simple à lire, nous avons ajouté des champs personnalisables. Par exemple, si ce qui compte pour vous est le ratio final sans tenir compte du temps passé, vous pouvez mettre 0 dans les poids de la compression et de la décompression pour calculer un score pondéré.

Avec 1 pour le poids final des fichiers et sans tenir compte des vitesses de compression et décompression, zpaq, BSC, 7zip-zz-ultra et brotli arrivent en tête avec le réglage max sur le niveau de compression. zpaq occupe même la première place dans 8 des 11 catégories.

Toutes les combinaisons sont possibles : un poids de 10 pour la taille finale, de 1 pour la vitesse de compression et de 20 pour la décompression par exemple. Les deux algorithmes qui arrivent en tête sont zstd et lz4.

Corollaire de ces résultats : aucun algorithme ne prend la tête sur l’ensemble des catégories et des mesures. Choisir un algorithme de compression est toujours un compromis entre performance, vitesse de compression et vitesse de décompression ; il n’y a pas de réponse universelle. Sans compter les types de données qui jouent un rôle important. Notre outil du jour permet justement d’aller à ce niveau de finesse.

Dans la fenêtre ci-dessous, développée avec l’aide d’une IA générative (Claude), nous vous proposons un résumé de toutes les mesures avec la possibilité de paramétrer les poids à la volée. Vous pouvez ainsi trouver l’algorithme qui vous convient le mieux en fonction de vos besoins.

Cet outil, comme bon nombre de ceux proposés par Next est réservé à nos abonnés.

À vous de jouer !

Il reste 7% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (4)

votre avatar
J'ai probablement lu l'article un peu vite mais je ne vois pas l'impact du nombre de coeurs sur la vitesse des opérations. En pratique, chez moi, avec un processeur multicœur intel d'entrée de gamme (Intel(R) Core(TM) Ultra 5 135H), xz est beaucoup plus rapide à la compression que zip car xz utilise plusieurs cœurs contrairement à zip.

un exemple sur une ensemble de données compressés avec xz (.tar.xz) et zip (.zip) :

décompression du fichier .tar.xz:
xzcat debian13-amd64-LXDE-modele4-vim.tar.xz |dd of=/dev/null
10212800+0 enregistrements en entrée
10212800+0 enregistrements en sortie
5228953600 octets (5.2 GB, 4.9 GiB) copiés, 9.61186 s, 544 MB/s


décompression du fichier .zip :
unzip -c debian13-amd64-LXDE-modele4-vim.zip |dd of=/dev/null
10212709+65 enregistrements en entrée
10212713+61 enregistrements en sortie
5228914151 octets (5.2 GB, 4.9 GiB) copiés, 43.6064 s, 120 MB/s
votre avatar
Quelqu'un aurait une URL pour le format de compression TAR ? J'ai demandé à mon Google favori, mais il ne me trouve que des choses en rapport avec le format d'archive tar, mais absolument rien sur un format de compression qui répondrait à ce nom. Ça m'intrigue.
votre avatar
Dans le tableau, TAR correspond à l’algorithme et non un format de compression, non ?

Parce que normalement, le fichier .tar n'est pas un format compressé. Le fichier est créé et ensuite compressé via un outil de compression.
fr.wikipedia.org Wikipedia
votre avatar
L'article teste des algorithmes de compression. Donc soit il existe un algo de compression qui s'appelle TAR, homonyme de l'outil d'archive, et que je ne connais pas (ce que j'ai cru initialement), soit l'article inclut par erreur le format d'archive tar dans le lot, sachant qu'il ne compresse pas : on colle juste un en-tête devant les données brutes, et c'est tout.
Le fait que TAR ne soit pas dernier partout me fait douter. Il existerait des algos de compression plus mauvais que de ne pas compresser ? Il arrive quand même 8ème sur 78 dans la synthèse pondéré. 90% des algos sont plus mauvais que quelque chose qui ne compresse pas ?

edit : vérification faite dans le fichier xlsx, TAR obtient bien un ratio de 1.00 partout, donc il s'agit bien du format d'archive sans compression. Je comprends encore moins le classement.