Je écriture du projet qui stocke des données, j'ai donc besoin de le comprimer. J'ai essayé Zlib mais c'est un goulot d'étranglement de mon projet. Alors peut-être qu'il y a une solution plus rapide. Je n'ai pas besoin d'un grand ratio compresse, mais je cherche une compression vraiment rapide. Existe-t-il d'autres bibliothèques de compression de données, à l'exception de ZLIB, qui sont vraiment gratuites et peuvent être utilisées dans des logiciels propriétaires (projet, je travaille sur, n'est pas basé sur GPL). Mon projet est sur C ++ et j'ai besoin de compresser Char * des tableaux de texte.
11 Réponses :
Un algorithme de compression très rapide est lzo . Les repères sur le site montrent que la décompression est comparable à la vitesse de la vitesse de La version gratuite de Lzo est autorisée par GPL, mais il existe également une version commerciale de la bibliothèque dans Lzo Professional . En outre, à partir de la documentation:
licences spéciales pour des applications commerciales et autres qui ne sont pas disposées à accepter la licence publique générale GNU sont disponibles en contactant l'auteur.
memcpy () .
Depuis que vous avez besoin de quelque chose qui est rapide mais pas nécessairement la meilleure compression de tous les temps, vous pouvez envisager une bibliothèque qui fait rle ( Encodage de la longueur d'exécution ) Compression. Une implémentation est LIBRE , qui est sous licence BSD, qui est assez admissible à une utilisation exclusive. < / p>
Oui, BZIP2 a une licence BSD.
bzip2 est généralement plus lent que gzip, bien que la meilleure compression
Je pense que 7ZIP est le domaine public. Compression Lzma.
7zip est (beaucoup?) plus lentement que "gzip" ou "bzip2". C'est le commerce habituel - plus lent, mais se compresse mieux.
Johne: Pas nécessairement. Mon E4500 comprime 100 Mo d'environ 10 secondes (compression LZMA).
lzo et liblzf approche memcpy () SPEEDS- Si je me souviens bien de la vitesse de fond de panier E4500 XDBUS correctement, ils compresseront tous les deux votre fichier de 100 Mo dans <1 seconde.
Il est généralement plus lent que GZIP, mais plus rapide que BZIP2. Il a une meilleure compression que les deux.
Une autre réponse déjà mentionne Un autre que j'ai trouvé est liblzf . Assez proche de lzo , qui est en quelque sorte la valeur par défaut "J'ai besoin de solution de compression plus rapide (DE)".
lzo en termes de vitesse et de vitesse de compression. lzo a une licence GPL, tandis que liblzf a une licence BSD (qui, IMHO, est un avantage).
Primitives de performance intégrées Intel a des échantillons qui implémentent la variété de compressions:
- Bibliothèque compatible BZIP2 L'exemple IPP_BZIP2 démontre comment utiliser les fonctions de domaine de compression de données Intel IPP pour la mise en œuvre de BZIP2 / LIBBZIP2 (programme et bibliothèque pour la compression de données sans perte, de tri et de nouvelles améliorations sur l'optimisation de la filetage pour BZIP
- Bibliothèque compatible GZIP L'exemple IPP_GZIP illustre la manière de mettre en œuvre une solution efficace de compression de données sans perte sans perte en utilisant API de domaine de compression de données Intel IPP. En outre, cet exemple montre les moyens de paralléser l'application à l'aide d'OpenMP et d'autres méthodes pour avantages avancés sur l'environnement multicœur.
- Bibliothèque compatible ZLIB (Nouveau!) Cet exemple de code illustre comment créer une bibliothèque de comptoir de données compatible ZLIB à l'aide des fonctions optimisées de codage LZ77 et Huffman dans Intel IPP.
- Exemples de compression généraux de données Illustrent comment utiliser les fonctions fournies par le domaine de compression de données Intel IPP. Inclut le codage / décodage de Huffman, le codage / décodage RLE, MOVETOFRONT (MTF), Transformations de BURrows-Wheeler (BWT), Transformation d'intervalle général (GIT) et Lempel-ZIV-Storer-Szymanski (LZSS).
IPP n'est pas gratuit, mais c'est vraiment rapide. Il prend en charge Windows et Linux.
Voici quelques-uns:
FastLZ - Fast et léger, licence MIT, sauf si vous souhaitez l'utiliser sous une licence GPL < / p>
LZJB - également rapide et assez léger, utilisé comme algorithme de compression par défaut pour les ZFS de Sun
Um non. LZ4 est 50% plus rapide au même ou meilleur rapport de compression que les deux FastLZ ( code.google.com/p / lz4 ) et lzjb ( wiki.illumos.org/display/illumos/ Compression LZ4 + ).
Je viens de remarquer que c'est une question plutôt ancienne. Je ne sais pas pourquoi il s'est apparu comme récent. Peut-être parce que quelqu'un vient de le modifier.
J'ai utilisé un LZSS Mise en œuvre de < Un href = "http://oku.edu.mie-u.ac.jp/~okumura/" rel = "nOfollow NOREFERRER"> Haruhiko Okumura . La licence n'est pas claire de son site mais Quelques Versions a été publié avec une ligne" Utiliser, distribuer et modifier ce programme librement "incluse et le code est utilisé librement par des vendeurs commerciaux.
Une autre option pourrait être le LZFX lib qui implémente LZF. Il est publié sous une licence BSD.
Haruhiko Okumuras Page indique: Sauf indication contraire, le contenu de ce site est sous licence à une licence Creative Commons Attribution 2.1 Japan.
Google a publié "Snappy", qui est une bibliothèque de compression sous licence BSD écrite en C ++ (liaison dans C incluse).
http://code.google.com/p/snappy/
Selon Readme dans la source:
Dans nos tests, Snappy est généralement plus rapide que les algorithmes dans le même classe (par exemple LZO, LZF, FastLZ, QuickLz, etc.) tout en réalisant Ratios de compression comparables.
En raison de problèmes liés à la licence de LZO, nous avons décidé d'évaluer les suggestions de ce fil sous licence BSD / MIT, sont très similaires à la LZO (pour une intégration plus facile) et conviennent à une exécution sur le matériel bas de gamme (pensez pas peu coûteux 32 bits MCU, pas pentium2).
Nous avons testé LZ4, LZF, FastLZ et comparé les résultats à LZO. Nous avons compressé des données graphiques. Je ne peux pas poster des résultats exacts, mais lz4 était considérablement plus rapide que d'autres (gagne en 7 tests, avec une marge allant jusqu'à 40% contre le second meilleur), tout en faisant correspondre la taille (5-2-2 gains pour LZF-LZ4-LZO, les marges étaient petites).