高性能压缩算法的目的除了存储效率

Question

在尝试学习基于 C++ 的 RAD 框架 U++ 的源代码时，我注意到它大量使用压缩/解压缩来读取和写入数据。 据我了解，压缩提供了以更紧凑的方式存储数据同时仍保持完整性的优势。

但是当我对 LZ4 算法进行更多研究时，一些消息来源提到它提供比直接读写更快的读/写（不幸的是，我无法再找到上述来源）。 我想知道为什么会这样，因为无论如何，仍然必须处理主要数据-压缩/解压缩只是另一个额外的步骤。 即使我们考虑像 Huffman 编码这样的基本压缩算法，我们仍然需要检查原始数据空间，因此例如常规读取就可以做到这一点。 但是压缩算法不仅必须执行该步骤，还必须进一步处理该信息。

鉴于常规 IO 操作和压缩/解压缩操作似乎都在执行初始数据空间读取，额外步骤的存在如何产生更快的处理。

U++ 似乎主要使用 zlib 库来编写/检索应用程序相关资源。 这样做仅仅是为了有效地利用空间，还是出于其他原因，比如上面提到的？

Answer 1

在 (c)pu 上编写和运行的代码在原始数据空间上运行*

（* 例外情况，代码可以考虑压缩方法并对其进行处理，例如，RLE 数据不需要为要实现的每个目标进行解压缩）

但是从持久数据到处理电路，存在相当多的中间存储

并且带宽会随着“管道”的不同而显着增加，并以不同的方式固定并呈指数增长：

sd/hdd/ssd -> (_RAM ->) 高速缓存 -> cpu/gpu 寄存器（后者带宽很少但吞吐量极高）

并且取决于 pu 是来自 2010 年还是 2022 年的“通用”PC PS5。

我目前没有找到任何来源或数据来概括这一点，但据我所知，压缩数据最初从慢速网络服务器（-连接）或硬盘移动到 ram 或客户端 PC，然后解压缩（完全或范围范围）由 cpu 放回 RAM 或缓存​​中，在处理数据之前的延迟可能比其他情况要短得多，在大多数情况下也是如此。

这取决于压缩比、解压缩工作量和带宽之间的管道片段以及传输的整体数据和预期的处理。

我没有在 U++ 网站上阅读任何有关压缩的信息。

减压是一个额外的步骤，需要时间（想想 + *=1.01 时间），但提前通过运输节省了更多时间（想想 - *=0.9 时间）。