除了存储效率外，高性能压缩算法的用途

Question

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

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

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

U++似乎主要使用zlib库编写/撤回与应用程序相关的资源。这样做是否只是为了有效地利用空间，还是出于其他原因，如上文所述？

Answer 1

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

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

但从持久化数据到处理电路，还存在不少中间存储。

随着“管道”的不同，带宽有了很大的提升，固定的带宽和费用的增长也是不同的：

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

这取决于聚氨酯是2010年还是2022年的“通用”PC的PS5。

目前，我没有发现任何源或数据会导致这种情况的泛化，但我记得，压缩数据最初从缓慢的and服务器(-connection)或hdd移动到ram或客户端PC，然后由cpu解压(完全或按范围排列)并放入RAM或缓存中，在处理数据之前可以大大缩短延迟时间，而且在大多数情况下都是如此。

Ofc --这取决于压缩比、解压缩努力和带宽与整个数据传输之间的管道段，以及对其的预期处理。

我没有在U++网站上读到任何关于压缩的内容。

解压缩是一个额外的步骤，占用时间(think + *=1.01时间)，但在传输之前节省了更多的时间(Thin-*=0.9时间)。