高性能壓縮算法的目的除了存儲效率

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 時間）。