From 542b18de485a99beebef87daa248da6a90b0c10b Mon Sep 17 00:00:00 2001 From: shijiashuai Date: Fri, 22 May 2026 15:18:43 +0800 Subject: [PATCH] docs: enrich algorithm notes with engineering insights and learning paths Add internal process explanations, engineering characteristics, tuning suggestions, and common pitfalls to each algorithm note. Add recommended learning path and algorithm map to the homepage. Expand comparison and guide sections with practical context. --- docs/zh/algorithms/brotli.md | 25 +++++++++++++++++ docs/zh/algorithms/bsc.md | 23 +++++++++++++++ docs/zh/algorithms/lz4.md | 29 +++++++++++++++++++ docs/zh/algorithms/lzma.md | 28 +++++++++++++++++++ docs/zh/algorithms/zlib.md | 25 +++++++++++++++++ docs/zh/algorithms/zstd.md | 28 +++++++++++++++++++ docs/zh/comparisons/matrix.md | 18 ++++++++++++ docs/zh/comparisons/scenarios.md | 24 ++++++++++++++++ docs/zh/examples/cpp-overview.md | 23 +++++++++++++++ docs/zh/guide/choosing-algorithms.md | 33 ++++++++++++++++++++++ docs/zh/guide/coding-models.md | 42 ++++++++++++++++++++++++++++ docs/zh/guide/compression-basics.md | 36 ++++++++++++++++++++++++ docs/zh/index.md | 17 +++++++++++ 13 files changed, 351 insertions(+) diff --git a/docs/zh/algorithms/brotli.md b/docs/zh/algorithms/brotli.md index 67c7d6e..ddfa1d8 100644 --- a/docs/zh/algorithms/brotli.md +++ b/docs/zh/algorithms/brotli.md @@ -6,6 +6,14 @@ Brotli 常用于 Web 内容压缩，尤其适合静态文本资源。它在压 Brotli 结合字典、上下文建模和熵编码，并内置静态字典来改善常见文本内容的压缩效果。 +## 为什么它在 Web 文本上常见 + +Brotli 的优势很大程度来自它对文本场景的优化： + +- 针对常见词片段和模式有静态字典。 +- 对 HTML、CSS、JS 这类结构化文本通常更友好。 +- 在“预压缩静态资源”场景里，压缩慢一点往往可以接受。 + ## 工程取舍 | 维度 | 特点 | @@ -16,12 +24,29 @@ Brotli 结合字典、上下文建模和熵编码，并内置静态字典来改 | 内存 | 依质量级别变化 | | 流式 | 支持 | +## 常见工程特征 + +- 很适合在构建阶段提前压好静态资源。 +- 在动态实时压缩场景里，要谨慎评估高级别开销。 +- 与 Web 分发、CDN、浏览器生态结合较紧密。 + ## 适用场景 - Web 静态资源 - 文本内容分发 - 对传输体积敏感的 HTTP 场景 +## 调参时通常先看什么 + +1. 是离线预压缩还是在线实时压缩。 +2. 质量级别是否值得拉高。 +3. 资源类型是否确实偏文本而不是二进制块数据。 + +## 使用时的常见坑 + +- 把高质量级别直接用在实时请求路径。 +- 用它去处理本就不适合文本字典优化的数据，再得出“Brotli 不行”的结论。 + ## C++ 示例 查看 [Brotli C++ 示例](/zh/examples/brotli)。 diff --git a/docs/zh/algorithms/bsc.md b/docs/zh/algorithms/bsc.md index 2dc2296..7266081 100644 --- a/docs/zh/algorithms/bsc.md +++ b/docs/zh/algorithms/bsc.md @@ -6,6 +6,17 @@ BSC 是一个适合学习块排序和上下文建模思想的压缩库。它的 BSC 通常围绕块级处理、排序变换和后续编码展开，让相似上下文聚集后再压缩。 +## 为什么它适合拿来学习 + +和很多“直接把重复找出来”的库不同，BSC 更容易让人看到这样一种思路： + +```text +先通过变换让数据局部结构更明显 + -> 再交给后续模型和编码处理 +``` + +它非常适合帮助建立“压缩不只是找重复，也可以先重排数据”的认知。 + ## 工程取舍 | 维度 | 特点 | @@ -16,12 +27,24 @@ BSC 通常围绕块级处理、排序变换和后续编码展开，让相似上 | 内存 | 块大小越大占用越高 | | 流式 | 更偏块处理 | +## 常见工程特征 + +- 对块大小比较敏感，块越大通常越有利于压缩率，但也越吃内存。 +- 更适合离线处理和实验，而不是极低延迟路径。 +- 在工程上经常需要额外关注构建方式和平台适配。 + ## 适用场景 - 学习块排序压缩 - 对特定数据集做实验性比较 - 离线批处理 +## 使用时的常见坑 + +- 把它当作“通用默认算法”通常不合适。 +- 忽略块大小带来的内存影响，会低估运行成本。 +- 在没有真实数据集验证前，很难单靠直觉判断它是否优于其他库。 + ## C++ 示例 查看 [BSC C++ 示例](/zh/examples/bsc)。如果当前平台无法自动构建 BSC，示例工程会把它作为可选目标处理。 diff --git a/docs/zh/algorithms/lz4.md b/docs/zh/algorithms/lz4.md index b7d2f40..d7f2781 100644 --- a/docs/zh/algorithms/lz4.md +++ b/docs/zh/algorithms/lz4.md @@ -6,6 +6,18 @@ LZ4 是一个以速度为核心目标的无损压缩算法，常用于实时系 LZ4 使用轻量级字典匹配，格式和实现都偏向快速压缩与快速解压。 +## 可以怎样理解它的设计哲学 + +LZ4 的重点不是“把每一个字节都压到极致”，而是： + +```text +尽快找到可接受的重复 + -> 尽快编码 + -> 尽快恢复 +``` + +因此它常常在系统热路径、缓存、流式传输、临时中间结果里非常有价值。 + ## 工程取舍 | 维度 | 特点 | @@ -16,6 +28,12 @@ LZ4 使用轻量级字典匹配，格式和实现都偏向快速压缩与快速 | 内存 | 低 | | 流式 | 支持 | +## 常见工程特征 + +- 实现简单，部署和调试成本较低。 +- 解压通常也非常快，这对读路径很重要。 +- 更像“用 CPU 换最小延迟”，而不是“用 CPU 换更高压缩率”。 + ## 适用场景 - 实时传输 @@ -23,6 +41,17 @@ LZ4 使用轻量级字典匹配，格式和实现都偏向快速压缩与快速 - 日志热路径 - 对延迟敏感的数据处理 +## 调参时通常先看什么 + +1. 是否直接用默认快速模式。 +2. 是否需要 frame 格式而不是裸 block 接口。 +3. 数据本身是否值得压缩；对高度随机数据它往往意义不大。 + +## 使用时的常见坑 + +- 把它和高压缩率算法直接比“最终文件大小”，容易误判它的定位。 +- 忽略整体延迟收益，只盯着压缩率，会错过它最核心的价值。 + ## C++ 示例 查看 [LZ4 C++ 示例](/zh/examples/lz4)。 diff --git a/docs/zh/algorithms/lzma.md b/docs/zh/algorithms/lzma.md index f17dbff..2fd003c 100644 --- a/docs/zh/algorithms/lzma.md +++ b/docs/zh/algorithms/lzma.md @@ -6,6 +6,16 @@ LZMA 常见于 xz/7z 生态，追求较高压缩率，代价是压缩速度和 LZMA 使用大窗口字典匹配和范围编码，并通过上下文建模提升压缩率。 +## 可以怎样理解它的内部流程 + +LZMA 的思路更偏“强模型”： + +```text +更深的匹配搜索 -> 更大的窗口 -> 更强的概率建模 -> 范围编码 +``` + +这也是它常常能拿到较高压缩率，但压缩端更慢、内存更高的原因。 + ## 工程取舍 | 维度 | 特点 | @@ -16,12 +26,30 @@ LZMA 使用大窗口字典匹配和范围编码，并通过上下文建模提升 | 内存 | 可较高 | | 流式 | liblzma 支持流式接口 | +## 常见工程特征 + +- 经常出现在 `xz` / `7z` 这类偏归档生态中。 +- 对窗口大小、字典大小、预设级别比较敏感。 +- 更适合“写一次、读多次，但写可以慢”的任务。 + ## 适用场景 - 软件包发布 - 长期归档 - 对压缩率更敏感而非压缩速度的场景 +## 调参时通常先看什么 + +1. **预设级别**：先决定压缩率与资源消耗的大致区间。 +2. **字典 / 窗口大小**：越大通常越有利于长距离重复，但也更耗内存。 +3. **流式还是一次性 buffer API**：取决于集成方式和数据规模。 + +## 使用时的常见坑 + +- 在内存受限环境下直接使用高预设，容易让体验失控。 +- 把它用于极度延迟敏感路径，通常得不偿失。 +- 只看压缩率，不看压缩时间，容易在 CI、构建链路、离线任务里造成明显拖慢。 + ## C++ 示例 查看 [LZMA C++ 示例](/zh/examples/lzma)。 diff --git a/docs/zh/algorithms/zlib.md b/docs/zh/algorithms/zlib.md index afcf10e..a2035ef 100644 --- a/docs/zh/algorithms/zlib.md +++ b/docs/zh/algorithms/zlib.md @@ -6,6 +6,14 @@ zlib 是 DEFLATE 生态中最常见的工程库之一。它不是最新的算法 DEFLATE 结合 LZ77 字典匹配和 Huffman 编码。zlib 提供稳定、广泛可用的接口。 +## 为什么它到现在还很重要 + +很多时候，zlib 的价值不在于“最强”，而在于“几乎到处都能用”： + +- 大量现有协议、格式和工具默认支持它。 +- 构建依赖轻，跨平台历史长。 +- 对很多业务来说，兼容性和稳定性比极限指标更重要。 + ## 工程取舍 | 维度 | 特点 | @@ -16,12 +24,29 @@ DEFLATE 结合 LZ77 字典匹配和 Huffman 编码。zlib 提供稳定、广泛 | 内存 | 较低 | | 流式 | 支持 | +## 常见工程特征 + +- 适合与 gzip / zlib 包装格式生态协同工作。 +- 既可以做简单 buffer 压缩，也可以做流式压缩。 +- 是许多“先上一个可靠方案”场景里的保守默认值。 + ## 适用场景 - 需要广泛兼容的文件或网络格式 - gzip/zlib 生态集成 - 老系统和跨平台组件 +## 调参时通常先看什么 + +1. 压缩级别是否需要从默认值提高。 +2. 是否需要流式接口配合网络或文件读写。 +3. 是否真正需要兼容 gzip / zlib 外层格式。 + +## 使用时的常见坑 + +- 用它和 Brotli、ZSTD 比较时忘记它的兼容性红利。 +- 认为“不是最新算法就不值得用”，忽略了部署现实。 + ## C++ 示例 查看 [zlib C++ 示例](/zh/examples/zlib)。 diff --git a/docs/zh/algorithms/zstd.md b/docs/zh/algorithms/zstd.md index e78108b..744d140 100644 --- a/docs/zh/algorithms/zstd.md +++ b/docs/zh/algorithms/zstd.md @@ -6,6 +6,16 @@ Zstandard 是一个面向通用场景的现代无损压缩算法，目标是在 ZSTD 结合字典匹配和熵编码。它支持多个压缩级别，低级别适合实时数据管道，高级别适合归档。 +## 可以怎样理解它的内部流程 + +可以把 ZSTD 粗略看成： + +```text +查找重复片段 -> 生成序列 -> 熵编码 -> 打包成 frame +``` + +它的优势不只是“压得不错”，而是允许你在一套生态里，从偏实时到偏归档做连续调节。 + ## 工程取舍 | 维度 | 特点 | @@ -16,6 +26,12 @@ ZSTD 结合字典匹配和熵编码。它支持多个压缩级别，低级别适 | 内存 | 随压缩级别增加 | | 流式 | 支持 | +## 常见工程特征 + +- 支持 frame 格式，适合文件和流式处理。 +- 支持字典训练，特别适合大量相似小对象。 +- 低级别常被用作系统默认压缩方案，因为总体平衡感很好。 + ## 适用场景 - 日志压缩 @@ -23,6 +39,18 @@ ZSTD 结合字典匹配和熵编码。它支持多个压缩级别，低级别适 - 本地缓存 - 可调压缩级别的归档任务 +## 调参时通常先看什么 + +1. **压缩级别**：最直接的速度 / 压缩率旋钮。 +2. **是否启用字典**：对小文本、短消息收益可能非常大。 +3. **是否流式**：会影响缓冲区和集成方式。 + +## 使用时的常见坑 + +- 用默认级别测一次就下结论，容易低估它的可调空间。 +- 用已经压缩过的数据做对比，结果常常没有参考价值。 +- 忽略字典训练，会错过它在“小而相似的数据”上的优势。 + ## C++ 示例 查看 [ZSTD C++ 示例](/zh/examples/zstd)。 diff --git a/docs/zh/comparisons/matrix.md b/docs/zh/comparisons/matrix.md index a87a04c..1d9f050 100644 --- a/docs/zh/comparisons/matrix.md +++ b/docs/zh/comparisons/matrix.md @@ -11,9 +11,27 @@ | zlib | 中 | 中 | 中到快 | 低 | 很高 | 兼容性优先 | | Brotli | 高 | 中到慢 | 快 | 中 | 高 | Web 文本资源 | +## 这些列应该怎么理解 + +- **压缩率**：不是绝对值，而是相对直觉；不同数据集差异非常大。 +- **压缩速度**：更多影响写链路、构建链路、离线任务。 +- **解压速度**：更多影响读链路、服务启动、请求响应。 +- **兼容性**：不仅是“能不能用”，还包括周边工具、协议和默认支持程度。 + ## 阅读方式 - 如果解压速度最重要，优先比较 LZ4 和 ZSTD。 - 如果压缩率最重要，优先比较 LZMA、ZSTD 高级别和 Brotli。 - 如果生态兼容性最重要，优先考虑 zlib。 - 如果目标是学习压缩变换，BSC 值得单独研究。 + +## 不同算法最容易被忽略的价值 + +| 算法 | 容易被忽略的点 | +| --- | --- | +| ZSTD | 它的价值不只是“平衡”，而是可调范围很大 | +| LZMA | 适合归档，不适合所有热路径 | +| BSC | 更适合作为学习与实验对象，而非默认基础设施组件 | +| LZ4 | 真正优势往往体现在系统延迟而不是压缩比 | +| zlib | 兼容性本身就是工程价值 | +| Brotli | 更适合文本和静态分发，不代表所有数据都优 | diff --git a/docs/zh/comparisons/scenarios.md b/docs/zh/comparisons/scenarios.md index dd89351..5f81271 100644 --- a/docs/zh/comparisons/scenarios.md +++ b/docs/zh/comparisons/scenarios.md @@ -4,21 +4,45 @@ 优先考虑 ZSTD 或 LZ4。ZSTD 提供更好的压缩率和可调级别，LZ4 更适合极低延迟路径。 +如果日志需要长期保留但也经常回放，ZSTD 往往是更稳的折中；如果日志只是短期缓冲或跨进程传递，LZ4 更容易获得低延迟收益。 + ## 长期归档 优先考虑 LZMA 或 ZSTD 高级别。如果数据偏 Web 文本资源，也可以比较 Brotli。 +这里最重要的是确认“写慢一点是否可以接受”。归档任务通常允许更慢压缩，但恢复时间和内存占用仍然要在演练中验证。 + ## Web 内容 优先考虑 Brotli 和 zlib。Brotli 更适合现代浏览器环境，zlib/gzip 兼容性更强。 +常见做法不是“二选一”，而是保留 gzip 兼容路径，同时为支持 Brotli 的客户端提供更小的资源。 + ## 嵌入式或低资源环境 优先关注内存和解压实现复杂度。LZ4 和 zlib 通常比高压缩率算法更容易控制资源。 +如果设备端主要负责解压而不是压缩，那么解压代码复杂度、二进制体积和峰值内存常常比理论压缩率更重要。 + +## 小文件和大量相似对象 + +这类场景往往值得优先考虑 ZSTD 的字典能力，或者至少专门测试“是否该引入字典训练”。 +单纯比较“不开字典时的大文件 benchmark”常常会错过真实收益点。 + ## 学习算法思想 - 字典匹配：LZ4、zlib、ZSTD、LZMA - 熵编码：zlib、ZSTD、Brotli - 上下文建模：LZMA、Brotli - 块排序：BSC + +## 一个简化的场景决策表 + +| 场景 | 更值得先试的算法 | 主要原因 | +| --- | --- | --- | +| 热路径、低延迟 | LZ4 | 极快 | +| 通用后端服务 | ZSTD | 综合最平衡 | +| 归档 / 发布包 | LZMA、ZSTD | 更重视压缩率 | +| 浏览器静态资源 | Brotli、zlib | 文本优化 + 兼容性 | +| 老系统 / 强兼容 | zlib | 生态成熟 | +| 学习变换类思路 | BSC | 便于理解块排序 | diff --git a/docs/zh/examples/cpp-overview.md b/docs/zh/examples/cpp-overview.md index 5ff0566..67c98b2 100644 --- a/docs/zh/examples/cpp-overview.md +++ b/docs/zh/examples/cpp-overview.md @@ -24,6 +24,29 @@ ratio=... verified=true ``` +## 这些示例刻意保持“最小闭环” + +它们不是性能 benchmark，也不是完整 SDK 封装，而是用来帮助你看清三件事： + +1. 一个压缩库最基础的 buffer API 长什么样。 +2. 压缩和解压分别需要哪些输入 / 输出缓冲区。 +3. 为什么任何学习示例都应该显式校验 round-trip 正确性。 + +## 阅读示例时建议关注什么 + +| 关注点 | 说明 | +| --- | --- | +| 输入如何读入 | 示例统一从文件读入字节数组 | +| 压缩缓冲区如何分配 | 多数库都需要先估算上界 | +| 解压输出大小如何确定 | 有的库能从 frame 获取，有的需要调用方自己知道 | +| 错误码如何处理 | 示例统一在失败时直接抛出异常 | +| 结果如何验证 | 统一比较原始字节和恢复字节 | + +## 为什么 BSC 还是占位示例 + +当前仓库已经支持把 BSC 作为可选目标构建，但文档仍然把它当作“学习构建接入和占位接口”的示例。 +原因不是它不重要，而是不同平台对上游构建和链接方式更敏感，后续更适合基于真实目标平台继续深化。 + ## 示例列表 - [ZSTD](./zstd) diff --git a/docs/zh/guide/choosing-algorithms.md b/docs/zh/guide/choosing-algorithms.md index 9ca2a0f..ada3c4b 100644 --- a/docs/zh/guide/choosing-algorithms.md +++ b/docs/zh/guide/choosing-algorithms.md @@ -20,3 +20,36 @@ 3. 格式是否需要被其他工具直接读取。 4. 数据是否有大量重复、结构化字段或自然语言文本。 5. 部署环境是否容易引入第三方库。 + +## 一个实用决策流程 + +### 第一步：先判断“读路径”还是“写路径”更重要 + +- 如果系统里读远多于写，优先看解压速度。 +- 如果是离线归档或构建产物打包，压缩速度可以牺牲一些。 +- 如果两边都重要，先从 ZSTD 这类可调节算法开始试。 + +### 第二步：确认生态约束 + +如果格式必须被浏览器、HTTP 中间件、老工具链、现有标准容器直接消费，那么兼容性可能比绝对性能更重要。 + +### 第三步：再决定是否引入更“重”的算法 + +只有在压缩率带来的收益足够大时，才值得引入更慢、更耗内存、构建更复杂的方案。 + +## 一个可以直接拿来用的经验表 + +| 你的目标 | 默认起点 | +| --- | --- | +| 不知道从哪开始，但想要比较稳妥 | ZSTD | +| 极致低延迟 | LZ4 | +| 必须和大量既有系统兼容 | zlib | +| Web 静态文本资源最小化 | Brotli | +| 归档优先、可接受慢压缩 | LZMA | +| 想专门学习块排序和变换思路 | BSC | + +## 常见反模式 + +- **只看默认配置。** 很多算法真正的差异会在级别、窗口、块大小、字典配置上拉开。 +- **在小样本上过早下结论。** 小文件和小数据集很容易被格式头或缓存效应误导。 +- **忽略总成本。** 引入新算法不只是引入一个函数调用，还包括构建、运维、监控和跨平台适配。 diff --git a/docs/zh/guide/coding-models.md b/docs/zh/guide/coding-models.md index f54653d..2acf4dc 100644 --- a/docs/zh/guide/coding-models.md +++ b/docs/zh/guide/coding-models.md @@ -6,14 +6,56 @@ 字典压缩把重复片段表示成“距离 + 长度”。窗口越大，越容易找到长距离重复，但内存占用和查找成本也会增加。 +### 你真正需要关注的不是“有没有字典”，而是“字典怎么找” + +- 有的算法偏向极快的启发式查找，适合低延迟场景。 +- 有的算法愿意花更多 CPU 做更深搜索，以换取更高压缩率。 +- 训练字典和预置字典适合大量相似小文件，但会引入额外的分发和版本管理问题。 + ## 熵编码 熵编码根据符号概率分配码长。高频符号使用短码，低频符号使用长码。Huffman 和算术/范围编码都属于这一类思想。 +### 为什么熵编码经常是“最后一公里” + +字典匹配或变换阶段负责把数据改造成“更容易压缩的形状”，熵编码再把这些符号分布真正压短。 +所以很多压缩库看起来像“一个大算法”，实际更像多阶段流水线。 + ## 上下文建模 上下文模型根据前面的字节或状态估计下一个符号的概率。模型越强，压缩率可能越好，但编码速度和内存成本通常更高。 +### 上下文为什么会更慢 + +因为它不仅在编码字节，还在不断更新“对下一个字节的预测”。这意味着更多状态、更多内存访问、更多分支判断。 + ## 块排序与变换 块排序类算法先改变数据排列，让相似上下文集中，再进行后续编码。BSC 这一类算法适合学习“变换 + 编码”的组合思路。 + +## 一个常见的简化心智模型 + +可以把很多压缩算法粗略理解为下面的处理链： + +```text +输入数据 + -> 重复片段抽取 / 结构变换 + -> 符号重组 + -> 概率建模 + -> 熵编码 + -> 输出格式封装 +``` + +不同算法的核心差异通常发生在前三步： +“找重复”的方式不同、“建模”的强度不同、“格式封装”的目标不同，最终就形成了非常不同的工程特性。 + +## 对照六个算法的理解抓手 + +| 算法 | 最适合先抓住的关键词 | +| --- | --- | +| ZSTD | 多级别调参、通用型、现代工程平衡 | +| LZMA | 大窗口、强模型、高压缩率 | +| BSC | 变换、块排序、离线处理 | +| LZ4 | 极快、简单、热路径友好 | +| zlib | DEFLATE、兼容性、广泛部署 | +| Brotli | 文本、静态字典、Web 分发 | diff --git a/docs/zh/guide/compression-basics.md b/docs/zh/guide/compression-basics.md index 2c53e1a..d2ecefc 100644 --- a/docs/zh/guide/compression-basics.md +++ b/docs/zh/guide/compression-basics.md @@ -22,6 +22,42 @@ decompress(compress(input)) == input | 块排序 | 重排数据让相似上下文聚集 | BSC | | 校验 | 发现传输或存储错误 | zlib、ZSTD | +## 评价压缩算法时不要只看压缩率 + +很多初学者会把“压得更小”当作唯一目标，但工程里通常要同时看下面几个维度： + +| 维度 | 真正关心的问题 | +| --- | --- | +| 压缩率 | 节省了多少带宽、磁盘和 CDN 流量 | +| 压缩速度 | 写入链路、离线任务或实时服务能否承受 | +| 解压速度 | 读取路径、启动路径、请求路径是否会被拖慢 | +| 内存占用 | 是否适合容器、边缘设备或多并发任务 | +| 流式能力 | 能否边读边压 / 边解压，而不是整块载入 | +| 格式兼容性 | 是否容易和现有工具、协议、生态集成 | + +## 数据特征会决定结果 + +同一算法在不同数据上可能表现完全不同： + +- 重复片段多、结构相似的数据，通常更适合字典匹配类算法。 +- 自然语言文本和 Web 资源，更容易从静态字典或上下文建模获益。 +- 已经压缩过、接近随机的数据，往往压不动，甚至会因格式头和元数据变大。 +- 小文件很多时，容器格式、块大小、字典训练方式经常比“算法名字”本身更关键。 + +## 实际使用时常见的三个误区 + +### 误区 1：把 benchmark 排名当成绝对结论 + +压缩测试高度依赖数据集、压缩级别、CPU、线程数和 I/O 环境。离开测试条件谈“某算法更强”通常没有意义。 + +### 误区 2：把压缩速度和解压速度混为一谈 + +很多系统真正的热路径是“读”，不是“写”。例如镜像拉取、服务启动、HTTP 响应、日志回放，经常更在意解压开销。 + +### 误区 3：忽略部署和维护成本 + +理论上更高压缩率并不总是更划算。如果引入新库会增加编译复杂度、部署体积、跨平台适配成本，整体收益可能反而下降。 + ## 学习建议 1. 先理解重复数据如何被引用。 diff --git a/docs/zh/index.md b/docs/zh/index.md index 5663877..9658f50 100644 --- a/docs/zh/index.md +++ b/docs/zh/index.md @@ -18,6 +18,23 @@ layout: home 这个站点用于沉淀压缩和编码算法的学习笔记。首版聚焦 ZSTD、LZMA、BSC、LZ4、zlib、Brotli，目标是把算法思想、工程取舍和 C++ 调用示例放在同一个可维护的知识库中。 +## 推荐学习路径 + +1. 先读「压缩基础」和「编码模型」，建立字典匹配、熵编码、上下文建模、块排序这些共通知识。 +2. 再横向比较 ZSTD、LZMA、LZ4、zlib、Brotli、BSC，形成“速度 / 压缩率 / 内存 / 兼容性”的基本直觉。 +3. 最后结合 `examples/cpp` 中的最小程序，把抽象概念映射到真实 API 调用和输出结果。 + +## 算法地图 + +| 方向 | 代表算法 | 你会重点学到什么 | +| --- | --- | --- | +| 通用现代压缩 | ZSTD | 如何在压缩率与吞吐之间做宽范围调节 | +| 高压缩率归档 | LZMA | 大窗口、范围编码、较强模型带来的收益和代价 | +| 极速低延迟 | LZ4 | 为什么很多系统宁愿牺牲压缩率也要换吞吐 | +| 兼容性优先 | zlib | DEFLATE 生态为何长期存在 | +| Web 文本压缩 | Brotli | 静态字典和文本场景优化 | +| 变换 / 块排序学习 | BSC | “先变换，再编码”的思路 | + ## 学习入口