{"id":2913,"date":"2026-05-04T13:56:18","date_gmt":"2026-05-04T11:56:18","guid":{"rendered":"https:\/\/elearningsamba.com\/index.php\/zxc-une-bibliotheque-de-compression-2x-plus-rapide-que-lz4\/"},"modified":"2026-05-04T13:56:18","modified_gmt":"2026-05-04T11:56:18","slug":"zxc-une-bibliotheque-de-compression-2x-plus-rapide-que-lz4","status":"publish","type":"page","link":"https:\/\/elearningsamba.com\/index.php\/zxc-une-bibliotheque-de-compression-2x-plus-rapide-que-lz4\/","title":{"rendered":"Zxc, une biblioth\u00e8que de compression 2\u00d7 plus rapide que LZ4"},"content":{"rendered":"

Deux fois plus rapide que LZ4 en d\u00e9compression ?? Ah bon c’est possible ? \u00c9videmment, quand Bertrand Lebonnois a publi\u00e9
\nzxc sur GitHub<\/a>
\n, et m’a envoy\u00e9 un email pour me pr\u00e9venir, j’ai \u00e9t\u00e9 jeter un \u0153il, surtout aux benchmarks.<\/p>\n

Eh bien apr\u00e8s analyse, c’est bien r\u00e9el !<\/p>\n

La philosophie de zxc est assez tranch\u00e9e vous allez voir. Il s’agit d’une lib WORM<\/strong> (Write-Once, Read-Many) qui permet de compresser une fois lentement, \u00e0 la compilation ou en CI, et ensuite de d\u00e9compresser comme vous voulez des millions de fois sur les appareils de vos utilisateurs \u00e0 la vitesse de l’\u00e9clair. Avec zxc, on accepte que la compression soit lente et complexe (pour trouver le bitstream parfait), afin que la d\u00e9compression soit m\u00e9ga rapide et simple pour le processeur. C’est aussi simple que \u00e7a.<\/p>\n

Le revers de la m\u00e9daille, c’est que si vous voulez de la compression \u00e0 la vol\u00e9e ou du streaming temps r\u00e9el, ce n’est clairement pas adapt\u00e9. Par contre, si vous produisez des assets une fois et qu’ensuite, vous les servez des milliers de fois, alors vous \u00eates exactement dans la cible.<\/p>\n

En pratique, sur macOS M2 avec un corpus de test standard, zxc d\u00e9passe les ~12 000 Mo\/s en d\u00e9compression, contre ~5 600 Mo\/s pour LZ4 --fast<\/code> dans le m\u00eame test. L’\u00e9cart reste \u00e9galement hyper solide ailleurs : 1,8\u00d7 sur ARM serveur (Google Axion) et 2\u00d7 sur x86_64 (AMD).<\/p>\n

\n\n<\/p>\n

Et l’API propos\u00e9e par zxc ne s’arr\u00eate pas \u00e0 un compresseur basique. En effet, un mode “seekable” permet d’acc\u00e9der \u00e0 n’importe quelle position d’une archive sans scanner le fichier depuis le d\u00e9but. Par exemple, vous packagez vos \nassets de jeux vid\u00e9o<\/a> \ndans une seule archive zxc, et quand le joueur charge une texture pr\u00e9cise, vous lisez directement le bon bloc, et pas tout le fichier.<\/p>\n

C\u00f4t\u00e9 installation, c’est simple : brew install zxc<\/code> sur macOS, apt install zxc<\/code> sous Debian ou Ubuntu, pip install zxc-compress<\/code>, npm install zxc<\/code>, cargo add zxc-compress<\/code> ou vcpkg install zxc<\/code> sous Windows.<\/p>\n

Des bindings officiels existent aussi pour Rust, Python, Node.js, Go et WASM et la communaut\u00e9 a aussi ajout\u00e9 Nim et Free Pascal de son c\u00f4t\u00e9. Et comme c’est cod\u00e9 en C, y’a aucune d\u00e9pendance lourde.<\/p>\n

Sache que pour assoir la cr\u00e9dibilit\u00e9 du projet, zxc a \u00e9t\u00e9 int\u00e9gr\u00e9 dans lzbench et TurboBench, les deux outils de r\u00e9f\u00e9rence permettant de comparer les algos de compression. Et le paquet est d\u00e9j\u00e0 dispo dans les versions testing et unstable de Debian, ce qui veut dire que les mainteneurs ont valid\u00e9 le truc !<\/p>\n

Bref, si vous g\u00e9rez de la compression d’assets ou de firmwares dans votre pipeline, \u00e7a vaut le coup d’y jeter un oeil.<\/p>\n

Merci \u00e0 Bertrand pour l’info et chapeau pour le boulot !<\/p>\n","protected":false},"excerpt":{"rendered":"