最快的实时解压算法

Question

我正在寻找一种实时解压缩数据块（1k-30k）的算法，希望开销最小。压缩速度最好快，但解压速度更为重要。

根据我的了解，LZO1X 应该是最快的算法。我有没有遗漏什么？理想情况下，该算法不应使用 GPL 许可证。

- Flawe

---

解压什么？文件？流？IP数据包？视频？使用什么编码？ - Dour High Arch

不压缩难道不是最快的压缩方式吗？ - Jens Schauder

如果解压缩速度超过了RAM速度（例如解压缩到L2/L3高速缓存），那么使用压缩可以比不使用更快。当使用磁盘或网络时，你的压缩优势可能会更大。 - Hynek -Pichi- Vychodil

Answer 1

LZ4是您在这里寻找的。

LZ4是一种无损压缩算法，具有每个核心400 MB/s的压缩速度，可随着多核CPU的扩展而提高。它具有极快的解码器，在多个GB/s每个核心的速度下运行，通常在多核系统上达到RAM速度限制。

- Mark Adler

Answer 2

试试谷歌的Snappy。

Snappy是一个压缩/解压库。它不旨在实现最大压缩率或与任何其他压缩库兼容；相反，它旨在实现非常高的速度和合理的压缩率。例如，与zlib的最快模式相比，对于大多数输入，Snappy的速度要快一个数量级，但生成的压缩文件的大小在20%到100%之间。在64位模式下的Core i7处理器的单个核心上，Snappy的压缩速度约为250 MB /秒或更快，解压速度约为500 MB /秒或更快。

- Randy Sugianto 'Yuku'

---

Yuku，我们注意到运行hadoop -text ${snappy_compressed_file}时的解压速度为10-12Mb/s（而维基百科声称为500Mb/s）。已安装Hadoop本地库（包括Snappy本地库）。有什么想法吗？我们的CPU信息（Amazon EMR）为Intel（R）Xeon（R）CPU E5645 @ 2.40GHz。 - Ivan Balashov

我的应用在1.2 GHz ARMv7处理器上运行，可以在100毫秒内解压5MB的数据。你是从内存中解压还是有I/O开销？ - Randy Sugianto 'Yuku'

感谢分享，Yuku。虽然涉及I/O操作，但与解压缩开销相比，开销相对较小。这里有一个更详细的关于snappy google group的同样问题：http://goo.gl/LBapFc - Ivan Balashov

Answer 3

当你无法使用GPL许可的代码时，你的选择很明确 - zlib。非常宽松的许可证，快速压缩，公平的压缩比，非常快速的解压缩，在任何地方都可以使用，并且已经移植到每一种合理的语言。

- Tometzky

---

这篇论文：http://www.kkant.net/papers/lzo_results.pdf声称LZO在解压速度方面比zlib快20倍（当然这会导致压缩性能变差）。 - MaR

是的，zlib在许多方面都很好，但在解压速度方面并不是最好的。我想到了类似QuickLZ这样的东西。 - Flawe

作为zlib的共同作者和维护者，我可以说这不是对这个问题的好回答。如果你允许更少有效的压缩，有更快的解压器。 - Mark Adler