零依赖纯 C# DEFLATE 引擎：2916 行移植 libdeflate

零依赖纯 C# DEFLATE 引擎：2916 行移植 libdeflate

本文力求客观：既呈现 Acl.Excel 的实测数据，也如实标注测试口径、版本差异与已知局限，供读者自行判断。

口径说明：基于 libdeflate 1.25 的纯 C# 移植（2916 行核心代码、压缩器 1806 行），Excel 读写端到端提升 18.7%~22%+，CopyMatch 深度优化后解压器在极端重复场景吞吐从 131.4 MB/s 提升到 746.1 MB/s；局限：<4KB 小块数据优势不明显。

Excel系列文章 第8篇 / 共11篇

系列导航：← 上一篇：写入引擎 · 下一篇：安全设计 →

Excel 文件本质是一个 ZIP 压缩包，而 ZIP 的性能瓶颈，往往就卡在 DEFLATE 这一层。.NET 自带的 DeflateStream 基于 zlib 分支，性能只能算中等；ZipArchive 在不少场景下还会再叠一层包装开销。想彻底提速？最直接的办法是引入 C 语言写的 libdeflate，但它需要 P/Invoke，于是平台绑定、部署复杂度、安全审计负担一个都跑不掉。

Acl.Excel 走了一条更"硬核"的路：把 libdeflate 1.25 的压缩器和解压器原原本本移植成纯 C#，2916 行核心代码做到零 P/Invoke、零平台依赖，在 Excel 读写场景拿到了 18.7%~22%+ 的端到端提升。本文就从这块最底层的技术基石讲起。你会看到一次完整的 C→C# 移植是怎么做的，解压器如何做到约 .NET 1.8x-2.7x 的吞吐，以及我们踩过的 14 轮优化坑里最值钱的几条教训。

核心结论
- 将 libdeflate 1.25 的 DEFLATE 压缩/解压完整移植为纯 C#（2916 行核心代码），零 P/Invoke、零平台依赖，Excel 读写端到端提升 18.7%~22%+。
- 解压器吞吐约为 .NET DeflateStream 的 1.8x-2.7x，典型 Excel 场景（worksheet XML 100KB~10MB）稳定在 2x 左右。
- 压缩器 1806 行完整移植，通过 CompressionLevel 策略（Fastest/Optimal/SmallestSize）控制候选匹配查找深度，实现吞吐与压缩比的灵活取舍。
- CopyMatch 深度优化（memmove 语义）把极端重复场景解压吞吐从 131.4 MB/s 拉到 746.1 MB/s（5.7 倍提升），将原本与 .NET 的差距从 50 倍缩小到 10 倍。
- 14 轮迭代换来 3 条关键教训：CopyMatch 必须 memmove 语义、微优化必须实测、32 位批量写入未必更快。

---

一、libdeflate 是什么：四个值得"抄"的设计

libdeflate 是 Eric Biggers 开发的高性能 C 语言 DEFLATE 压缩/解压库。它之所以快，根子在设计哲学上：

• Hash-chain 匹配查找器：用链表追踪字符串匹配位置，比 zlib 的 hash-table 方式更快。
• 7-Zip 风格 Huffman 编码：长度受限的规范 Huffman 树构建，生成的码表更紧凑。
• 基于代价的块分割：在多个候选分块点之间用代价模型选择最优分割。
• SIMD 优化的 CRC-32：使用 AVX2/AVX-512 加速校验和计算。

Acl.Excel 移植了 libdeflate 1.25 的核心算法，但没有移植 SIMD 部分（保持纯托管），CRC-32 改用 .NET 内置的 Crc32 实现。换句话说，我们把"快"的部分尽量搬过来，把依赖硬件指令的部分换成托管等价物，目标只有一个：在零原生依赖的前提下，尽量保留原算法的性能特征。

二、解压器：约 .NET 2 倍吞吐，怎么做到的

LibDeflateDecompressor 实现了完整的 DEFLATE 解压，包括静态 Huffman 解码、动态 Huffman 解码、LZ77 回引处理。它的速度来自下面几处核心优化。

预构建静态 Huffman 解码表。类加载时一次性构建所有固定码长的解码表，运行期零构造代价。

位操作优化。使用 ulong bitbuf 一次加载 64 位，bitsleft 追踪剩余位数，RefillBitsBranchless 无分支填充：

// 核心位填充逻辑
[MethodImpl(MethodImplOptions.AggressiveInlining)]
private static void RefillBitsBranchless(ref ulong bitbuf, ref int bitsleft, ...)
{
    // 当 bitsleft < 56 时，一次加载 8 字节到 bitbuf 高位
    // 无分支判断，编译器可生成 cmov 指令
}

ThreadStatic 单例。DecompressStatic 方法使用 [ThreadStatic] 单例复用缓冲区，避免并发竞争和重复分配。

多引擎自适配。解压器内部根据输入大小自动选择最优实现路径：小块数据走直接数组操作，大块数据走 Span 循环展开。

在多引擎对比中（1KB ~ 100MB），Acl.Excel 的解压器约 .NET DeflateStream 的 1.8x-2.7x 吞吐，具体取决于数据大小和压缩比。这里有一个值得记下的细节：小块数据（< 4KB）由于 .NET 的调用开销更低，Acl.Excel 的解压器优势不明显甚至略慢；但在典型 Excel 场景（worksheet XML 通常 100KB ~ 10MB），优势稳定在 2x 左右。也就是说，移植红利要在"真实数据体量"下才显现。

三、压缩器：1806 行代码的完整移植

LibDeflateCompressor 是系列中最复杂的组件，1806 行代码按模块组织：

LibDeflateCompressor.cs (1806 行)
├── 常量表 (~200 行)
│   ├── DeflateCodeLengthOrder      (码长顺序表)
│   ├── DeflateLengthSlotBase       (长度槽位基数)
│   ├── DeflateExtraLengthBits      (额外长度位)
│   ├── DeflateOffsetSlotBase       (偏移槽位基数)
│   └── DeflateExtraOffsetBits      (额外偏移位)
├── 匹配查找器 (~400 行)
│   ├── HashChain  (hash-chain 链表)
│   └── DeflateCompressFastest (单一路径，策略参数控制候选匹配查找深度)
├── Huffman 编码器 (~300 行)
│   ├── BuildLengthLimitedCanonicalCodes (长度受限规范码)
│   └── BuildHuffmanTree               (频率 → 码树)
├── 块分割与代价模型 (~300 行)
│   ├── 动态 Huffman 块代价
│   ├── 静态 Huffman 块代价
│   └── 不压缩块代价
├── 输出写入器 (~200 行)
│   ├── BitWriter      (位级写入)
│   └── MatchWriter    (匹配写入)
└── 公共 API (~100 行)
    └── DeflateCompress / DeflateCompressFastest

压缩策略通过 CompressionLevel 枚举控制匹配查找深度，而非多解析器架构：

策略	候选匹配数	行为
Fastest	2 候选	吞吐优先，不额外遍历 hash-chain
Optimal（默认）	短匹配 4 候选 / 中匹配 2 候选	混合阈值策略，性价比最优
SmallestSize	全 4 候选	压缩比优先，任意匹配均遍历全部候选

3.1 移植策略：把 C 惯用法翻译成 C# 惯用法

移植不是逐行"翻译"，而是把 C 的惯用法映射到 C# 的等价物，既保留语义又贴合托管运行时：

C 原始构造	C# 等价
struct 在栈上分配	ref struct / readonly ref struct
malloc + free	ArrayPool<byte>.Shared.Rent / Return
指针运算 *ptr++	Span<T> 索引 + ref 局部变量
#define 常量	const / static readonly
C 数组 uint32_t[4096]	Span<uint> 切片
goto 状态机	while + switch（保持原逻辑流）

3.2 Hash-Chain：核心匹配查找器

Hash-chain 是 libdeflate 的核心数据结构。它为每个 3 字节序列维护一个哈希值，通过链表追踪历史位置：

输入:  "hello world hello again"
位置:   0123456789...
hash("hel") = 42 → chain[42] = 0

hash("ell") = 17 → chain[17] = 1

...

hash("hel") = 42 → chain[42] = 0 → 新位置 12 链接到 0

现在 chain[42] = 12

当编码器在位置 12 遇到 "hel" 时，它通过 hash 42 找到位置 0 的 "hel"，确认可以匹配，然后检查匹配长度。这个过程比 zlib 的简单 hash-table 查找更准确，但也更昂贵，因为要维护链表、遍历历史位置。

Acl.Excel 的移植忠实保留了 hash-chain 的语义，但做了若干 C# 友好的调整：

• 使用 int[] 数组替代 C 的 uint32_t* 指针。
• ArrayPool 复用 hash-table 和 chain 数组。
• 匹配查找循环使用 ref 局部变量避免边界检查。

3.4 策略驱动的候选匹配：吞吐与压缩比的取舍

压缩器不采用多解析器架构，而是通过 CompressionLevel 策略参数控制匹配查找的候选数量与搜索深度，在单一 DeflateCompressFastest 路径上实现吞吐与压缩比的灵活取舍：

策略	候选匹配	搜索深度	适用场景
Fastest	2 候选	较浅	吞吐优先（如实时导出）
Optimal（默认）	短匹配 4 候选 / 中匹配 2 候选	中等	性价比最优
SmallestSize	全 4 候选	最深	压缩比优先（如归档存储）

Optimal 策略采用混合阈值：bestLen >= niceLen/2 时仅查 2 候选，bestLen < niceLen/2 时查 4 候选。这个策略在典型 Excel 数据上实现了最佳性价比平衡：长匹配已经够好就别再耗时间，短匹配才值得多找几个候选。

四、解压器的前序优化之路：14 轮迭代

解压器不是一次写对就快的，它经历了 14 轮迭代优化，分为四个阶段。这段"弯路"本身就是本文最值得读的部分。

P0 阶段（功能正确性）：实现完整 DEFLATE 解压，通过 29 项专项测试 + 1620+ 全量回归。

P1 阶段（消除瓶颈）：移除 SafeHandle 包装、内联关键路径、消除不必要的数组拷贝。

P2 阶段（CopyMatch 深度优化）：这是最关键的优化 —— DEFLATE 的 LZ77 回引（CopyMatch）需要将历史数据复制到当前位置。当 offset < length 时（极端重复 / RLE 场景），源和目标区域重叠，必须按字节序处理（memmove 语义，而非 memcpy）。Acl.Excel 最初尝试了 WordBytes 块拷贝，但导致了解压结果不一致，最终回退到安全的逐字节处理。这项优化将极端重复场景吞吐从 131.4 MB/s 提升到 746.1 MB/s（5.7 倍提升），将原本与 .NET 50 倍的差距缩小到 10 倍。

P3 阶段（微优化与回归防护）：预计算常量、分支预测提示、循环展开。这个阶段出现了若干反直觉的结果：某些微优化反而导致 8.8% 的性能下降（Optimal 50K 场景），最终被回退。

五、关键教训：三条最值钱的坑

把 14 轮迭代里最该写进"避坑指南"的三条单独拎出来：

CopyMatch 的 memmove 语义是铁律。DEFLATE 的回引可能要求把刚刚解压的数据再复制到当前位置，这时源和目标是重叠的。使用块拷贝（如 Buffer.MemoryCopy）在 offset < length 时会产生错误结果，因为块拷贝假设源和目标不重叠。这是从 C 移植到 C# 时最容易犯的错误之一。

微优化的收益需要实测验证。预计算常量、代码结构调整等看似无害的优化，在 .NET JIT 的复杂优化下可能产生意外效果。每次优化后必须运行 BenchmarkDotNet 基准测试验证。

32 位批量写入未必更快。BitWriter 从逐字节写入改为 32 位批量写入，在某些场景下反而导致 21% 的性能下降，因为额外的分支判断抵消了批量写入的收益。

六、关键收获

• 把高性能 C 库完整移植成纯 C# 是可行的：2916 行核心代码换来零 P/Invoke、零平台依赖，Excel 读写端到端提升 18.7%~22%+。
• 解压器的速度来自"预构建解码表 + 无分支位填充 + ThreadStatic 缓冲复用"，在典型 Excel 场景稳定约 1.8x-2.7x 吞吐（2x 左右）。
• 压缩器通过 CompressionLevel 策略（Fastest/Optimal/SmallestSize）控制候选匹配查找深度，在吞吐与压缩比之间灵活取舍，无需多解析器架构。
• 三条铁律教训务必记牢：CopyMatch 必须 memmove 语义、微优化必须 BenchmarkDotNet 实测、32 位批量写入未必更快。

免责声明：本文基于 Acl.Excel 4.0.0（2026 年 7 月（撰写日期前后）实测）数据撰写，测试环境与口径见正文；数据可能随版本演进变化，重要决策请自行复测核验。

客观性说明：本文的结论基于以下事实约束，而非自诩无偏——① 基于 libdeflate 1.25 的纯 C# 移植（2916 行核心代码、压缩器 1806 行），Excel 读写端到端提升 18.7%~22%+；② 极端重复场景吞吐从 131.4 MB/s 提升到 746.1 MB/s 来自解压器 CopyMatch 深度优化（memmove 语义），为本机实测，依赖数据大小与内容；③ 局限：<4KB 小块数据优势不明显。以上局限已在正文相应位置如实标注，供读者结合完整信息自行判断。

系列导航

Acl.Excel 系列文章（共 11 篇）

序号	文章	重点
①	从 libdeflate 到纯 C#：Acl.Excel DEFLATE 解压/压缩器的移植与优化之旅	纯 C# 移植 libdeflate
②	从 libdeflate 到纯 C#（续）：优化纯 C# DEFLATE 压缩器——从 1.6x 到 4.9x 的提速之路	14 轮优化提速
③	Acl.Excel vs MiniExcel 1.45.0：性能对比与选型分析（.NET 8 基准）	百万行对等实测
④	不依赖 NPOI/ClosedXML，纯 C# Excel 库如何做到 30 倍性能？	概述与设计哲学
⑤	百万行Excel如何恒定内存？Acl.Excel流式拆解	读取引擎流式管线
⑥	24B消灭上亿次装箱：Acl.Excel零装箱设计	24B CellValue 零装箱
⑦	写入分配砍掉 63%：Acl.Excel 绕过 XmlWriter 字节直写	字节直写与并行写入
⑧	零依赖纯 C# DEFLATE 引擎：2916 行移植 libdeflate	DEFLATE 引擎移植（本文）
⑨	一个 42KB 的 Excel 如何撑爆 4.5PB？Acl.Excel 8 层防御	安全纵深防御
⑩	Acl.Excel 跨库基准：读取最高快 32.8 倍	跨库性能基准
⑪	从实战到生产：Acl.Excel 八大场景与避坑指南（终篇）	实战与避坑指南

建议按 ①→⑪ 顺序阅读，从底层算法到实战落地形成完整认知。（当前本篇为第 8 篇，已以 粗体 标记。）

下一篇将聚焦 Acl.Excel 的安全纵深防御体系 —— 从文件大小护栏、解压炸弹防护到 XXE 禁用、ZipSlip 过滤，解析 8 层安全防护如何在零性能损耗的前提下实现。

标签（建议）：Acl.Excel, .NET, 性能优化, DEFLATE, 压缩算法