Sto cercando un algoritmo per decomprimere blocchi di dati (1k-30k) in tempo reale con un sovraccarico minimo. La compressione dovrebbe preferibilmente essere veloce ma non è importante quanto la velocità di decompressione.Algoritmo di decompressione in tempo reale più veloce
Da quello che potrei raccogliere LZO1X sarebbe il più veloce. Ho perso qualcosa? Idealmente l'algoritmo non è sotto GPL.
Quando non è possibile utilizzare il codice con licenza GPL, la scelta è chiara - zlib. Licenza molto permissiva, compressione veloce, rapporto di compressione corretto, decompressione molto veloce, funziona ovunque e viene trasferito in ogni linguaggio sano.
Questo documento: http://www.kkant.net/papers/lzo_results.pdf rivendica 20 volte il vantaggio della velocità di decompressione di LZO rispetto a zlib (ovviamente con peggioramento delle prestazioni di compressibilità). – MaR
Sì, zlib è bravo in molte cose, ma non è il massimo a velocità di decompressione. Avevo in mente qualcosa come QuickLZ. –
Come coautore di zlib e manutentore di zlib, posso dire che questa non è una buona risposta a questa domanda. Ci sono decompressori molto più veloci, se si consente una compressione meno efficace. –
Prova Google Snappy.
Snappy è una libreria di compressione/decompressione. Non mira alla compressione massima o alla compatibilità con qualsiasi altra libreria di compressione; punta invece a velocità molto elevate e compressione ragionevole. Ad esempio, rispetto alla modalità più veloce di zlib, Snappy è un ordine di grandezza più veloce per la maggior parte degli input, ma i file compressi risultanti sono ovunque dal 20% al 100% più grandi. Su un singolo core di un processore Core i7 in modalità 64 bit, Snappy si comprime a circa 250 MB/sec o più e decomprime a circa 500 MB/sec o più.
Yuku, osserviamo una velocità di decompressione di 10-12Mb/sec (rispetto a 500Mb/s rivendicata su wiki) con "hadoop -text $ {snappy_compressed_file}". Le librerie native di Hadoop sono installate (incluso il snappy native). qualche idea? La nostra CPU Info (Amazon EMR) CPU Intel (R) Xeon (R) E5645 @ 2,40 GHz –
La mia app in esecuzione su processore 1.2 Ghz ARMv7 decomprime 5 MB di dati in 100 ms. Hai decompresso dalla memoria o ci sono sovraccarico I/O? – yuku
Grazie per aver condiviso, Yuku. Vi è un I/O coinvolto, tuttavia, il sovraccarico è piuttosto trascurabile rispetto al colpo di decompressione. Ecco la stessa domanda con un po 'più dettagli sul gruppo di Google snappy: http://goo.gl/LBapFc –
lz4 è quello che stai cercando qui.
LZ4 è algoritmo di compressione senza perdita di dati, fornendo velocità di compressione a 400 MB/s per core, scalabile con le multi-core CPU. È dotato di un decoder estremamente veloce , con velocità in più GB/s per core, che in genere raggiunge i limiti di velocità della RAM su sistemi multi-core.
Decompressione di cosa? File? Flussi? Pacchetti IP? Video? Quale codifica? –
La compressione più veloce non dovrebbe essere la compressione? –
@JensSchauder: Assolutamente no, se la decompressione supera la velocità della RAM (decompressione nella cache L2/L3 per esempio), è possibile ottenere più velocità dalla compressione piuttosto che senza. Quando si utilizza il disco o la rete, il vantaggio di compressione può essere persino maggiore. –