Je recherche un algorithme pour décompresser des morceaux de données (1k-30k) en temps réel avec une surcharge minimale. La compression doit de préférence être rapide mais n'est pas aussi importante que la vitesse de décompression.
De ce que je pouvais rassembler, lzo1x serait le plus rapide. Ai-je raté quelque chose? Idéalement, l'algorithme n'est pas sous GPL.
3 Réponses :
Lorsque vous ne pouvez pas utiliser de code licencié GPL, votre choix est clair - ZLIB . Licence très permissive, compression rapide, ratio de compression équitable, décompression très rapide, fonctionne partout et porté à chaque langue sane.
Ouais, Zlib est bon à beaucoup de choses, mais ce n'est pas le meilleur des vitesses de décompression. J'ai eu quelque chose comme Quicklz à l'esprit.
En tant que co-auteur Zlib et le responsable de la ZLIB, je peux dire que ce n'est pas une bonne réponse à cette question. Il existe de nombreux décompresseurs plus rapides, si vous autorisez une compression moins efficace.
Essayez Google's Snappy .
Snappy est une bibliothèque de compression / décompression. Il ne vise pas une compression maximale ou une compatibilité avec une autre bibliothèque de compression; Au lieu de cela, il vise à très grande vitesse et à une compression raisonnable. Par exemple, comparé au mode le plus rapide de zlib, Snappy est un ordre de grandeur plus rapide pour la plupart des entrées, mais les fichiers compressés résultants sont entre 20% et 100% plus importants. Sur un seul noyau d'un processeur Core I7 en mode 64 bits, Snappy compresse à environ 250 Mo / s ou plus et se décompresse à environ 500 Mo / sec ou plus.
Yuku, nous observons la vitesse de décompression de 10-12 Mo / SEC (VS 500MB / s revendiquée sur wiki) exécutant hadoop -text $ {snappy_compressed_file} . Hadoop Native Libs sont installés (y compris native snappe). Des pensées? Notre info CPU (Amazon EMR) Intel (R) Xeon (R) CPU E5645 @ 2.40GHz
Ma propre application fonctionnant sur 1,2 GHz Armv7 processeur décompresse 5 Mo de données à 100 ms. Avez-vous décompressé de la mémoire ou il y a des frais généraux d'E / S?
Merci de partage, Yuku. L'E / S est impliqué, cependant, les frais généraux sont plutôt négligeables par rapport à la décompression touchée. Voici la même question avec un peu plus de détails sur Snappy Google Group: goo.gl/LBAPFC
LZ4 est ce que vous recherchez ici.
lz4 est un algorithme de compression sans perte, offrant une vitesse de compression à 400 Mo / s par noyau, évolutif avec la CPU multi-noyaux. Il comporte un décodeur extrêmement rapide, avec vitesse dans plusieurs Go / s par noyau, atteignant généralement des limites de vitesse de RAM sur des systèmes multicœurs.
Décompression de quoi? Des dossiers? Ruisseaux? Paquets IP? Vidéo? Quel codage?
Ne serait pas la compression ne serait pas la compression la plus rapide?
@Jensschauder: Certainement non, si la décompression dépasse la vitesse de la RAM (décompression dans le cache L2 / L3 par exemple), vous pouvez obtenir plus de vitesse par compression que sans elle. Lorsque vous utilisez le disque ou le réseau, votre avantage de compression peut être encore plus gros.