压缩流的能力如何影响压缩算法？答案

【问题标题】：How does the ability to compress a stream affect a compression algorithm?压缩流的能力如何影响压缩算法？
【发布时间】：2011-08-22 17:46:54
【问题描述】：

我最近备份了我即将到期的大学主目录，将其作为 tar 流发送并在我端压缩：ssh user@host "tar cf - my_dir/" | bzip2 > uni_backup.tar.bz2。

这让我开始思考：我只知道压缩工作原理的基础知识，但我想这种压缩数据流的能力会导致压缩效果变差，因为算法需要在某一时刻完成对数据块的处理，将其写入输出流并继续下一个块。

是这样吗？还是这些程序只是简单地将大量数据读入内存，压缩它，写入它，然后再重复一遍？还是在这些“流压缩器”中使用了任何巧妙的技巧？我看到 bzip2 和 xz 的手册页都在讨论内存使用情况，而 man bzip2 也暗示了这样一个事实，即几乎没有丢失将要压缩的数据切成块：

较大的区块大小会导致边际收益迅速递减。大多数压缩来自前两三百 k 的块大小，在小型机器上使用 bzip2 时值得牢记这一事实。同样重要的是要了解解压缩内存要求是在压缩时通过选择块大小来设置的。

我仍然很想知道是否使用了其他技巧，或者我可以在哪里阅读更多相关信息。

【问题讨论】：

好问题；我只想指出，通过像bzip2 这样的压缩程序传输数据流并不一定意味着小块数据正在被实时压缩和发送。您可以轻松地拥有一个压缩实用程序，它会吃掉发送给它的所有数据，直到达到 EOF，然后才压缩它并发送它。
我不希望 bzip2 在开始写入输出的第一个字节之前分析几个 gig 的数据。这可能会在最终大小中节省几个字节，但我们也都想要性能。但是，是的，我也喜欢你的问题。

【解决方案1】：

这个问题更多地涉及缓冲区处理而不是压缩算法，尽管也可以说一点。

一些压缩算法本质上是“基于块的”，这意味着它们绝对需要处理特定大小的块。这是 bzip2 的情况，通过“级别”开关选择块大小，从 100kb 到 900kb。因此，如果您将数据流式传输到其中，它将等待该块被填充，并在该块已满时开始压缩该块（或者，对于最后一个块，它将以接收到的任何大小工作）。

其他一些压缩算法可以处理流，这意味着它们可以使用保存在内存缓冲区中的旧数据不断压缩新数据。基于“滑动窗口”的算法可以做到这一点，通常 zlib 能够做到这一点。

现在，即使是“滑动窗口”压缩器也可以选择将输入数据切割成块，以便更轻松地管理缓冲区或开发多线程功能，例如 pigz。

【讨论】：