Bonjour,
Aujourd’hui nous allons parler de compression de données lossless (sans changement de l’information).
Cela vas s’appliquer surtout au MMORPG CatchChallenger sur les points suivant: données de taille petite et moyenne, fortement compressible (xml, base64 continue).
Choix de la compression
Même si dans ce post se n’est pas le but, il faut bien choisir votre compression en fonction de votre système. Si vous voulez plus de bande passante en échange de cpu, si vous faites la compression dynamiquement ou non, …
Réduire l’entropie
Nous allons avant tout commencer à reduire l’entropie. Vous devez donc supprimer toutes les données aléatoire inutile. Et faire que celle utile forme des suites.
Isoler les bloques aléatoires
Quand un bloque de donnés viens couper des données similaire:
items/1073.png 1 XXXX
items/1149.png 1 XXXX
items/1178.png 1 XXXX
Cela casse la compression (le système de compression switch tout le de temps compressé a non compressé). Cela n’as pas d’importance sur les grands bloque car le changement de mode est mineur vis a vis de la taille du bloque à compresser. L’idée est donc de les mettre la la fin pour que la compression soit maximal d’un coté et que le système de compression marque simplement un gros bloque comme non compressible.
items/1073.png 1
items/1149.png 1
items/1178.png 1
XXXX
XXXX
XXXX
Cela fait gagné 20% sur le format au dessus.
Binaire et pas hexa
Les formats de compression sont très sensible aux données non compressibles, les mettre en binaire et pas en hexa permet de réduire leur taille (10%).
Contenu
En fonction du contenu ET de la taille certaine compression seront plus avantageuse. Par exemple la zlib/gzip est plus efficace que xz/lzma sur les packet <300o.
Il n’y as pas une compression meilleur que les autres, chaque une ont leurs caractéristiques et leurs caractéristiques vis à vis de certaines données.
Zopfli
Zopfli permet de garder le format de compression actuel, mais à énormément besoin de cpu, ne jamais l’utiliser en dynamique. Il réduit de 10% à 50% la taille de vos compressions zlib/gzip (donc png aussi)
Mon outils tmxTileLayerCompressor pour compresser les bloques zlib dans les tmx avec zopfli permet de réduire la taille des tmx même sous leur forme compressé d’environ 10%.
Chose étonnante je ne constate pas de réduction de taille du datapack.tar.xz comme prévu. Idem coté tar sans xz, je pense que la modification est noyé dans un volume tellement gros d’informations qu’elle n’as pas d’influence. Par contre sur les pngs zopfli a une une influence notable.
Brotli
Je doit tester cette compression qui semble sympa surtout pour le streaming réseau avec des bloques de plus de 800o. Une compression proche de xz pour le statique, mais plus performant que gzip en -6 pour le streaming réseau tout en conservant un trés bon ratio. Mais hélas je trouve qu’il est trop orienté décompression, car la compression est bien trop lente mon gout, où en -6 c’est trés proche ou inférieur au ratio de zlib en fonction du contenu. Comme zlib: C’est parallélisable? Possible accélération hardware?
Voir le super lien: https://quixdb.github.io/squash-benchmark/
Lossy
Pour certain fichier comme les png/audio, les compressions sont lossless (sans perte de qualité/informations) mais j’ai appliquer un filtre de compression lossy (perte de qualité/informations) pour réduire la taille.
CatchChallenger
Voila les résultats spécifiques à CatchChallenger pour la liste des fichiers à télécharger:
Binaire 7% de taille en moins pour gzip
Suppression des retours de ligne pour les hash partiel (données non compressibles: réduction de 10% pour xz, 7% pour gzip
La spéparation en deux fichier (l’un compressé l’autre non) fait gagné 100o mais qui sont perdu par le protocole http (2x les entêtes pour les deux fichiers)
Répartition de la taille pour la base:
* 7Ko pour la liste de fichiers
* 500o pour la taille des fichiers
* 12Ko pour les hash partiel (non compressible)
Répartition de la taille pour le main:
* 2200o pour la liste de fichiers
* 500opour la taille des fichiers
* 2200opour les hash partiel (non compressible)