3.1 多核利用#

以计算为主的数据测纯计算能力：cpu_corpus 压缩后只有 896 MiB，往返全都落在系统内存里，几乎不碰硬盘。倍率以 1 个核心为基准。

计算侧上限为 6.00 倍。8 个核心到 16 个核心只多 1.20 倍，因为后 8 个是超线程，不是真核心。

换成 NCIEP 这样的真实数据，倍率大幅缩水：

单元格里的值是重复测量的平均值，1 个核心与 16 个核心各测了两次。

压缩只到 1.49 倍，解压 1.81 倍，远达不到计算侧的 6.00 倍。而且 8 个核心和 16 个核心基本一样，说明再加核心已经没有用了。

3.2 卡在哪#

两个对照实验用来分清到底是计算慢还是读写慢：

第二条是关键：完全不压缩、不加密，16 个核心的吞吐是 306.9 MiB/s，而正常压缩加密是 306.7 MiB/s，两者一模一样。计算时间被完全藏在了读写后面，一点都没体现出来。

硬盘单独跑有多快：

硬盘单独读同一份数据能到 2,100 MiB/s，而程序这条路径只跑到约 306 MiB/s，差约 7 倍。

文件个数的影响也很直接：同样是 13 GiB 左右的数据，分成 16 个大文件时吞吐是 453.4 MiB/s，分成 45,390 个小文件时掉到 306.7 MiB/s，少了三成。

结论是卡在读和写这一条线，不是压缩算法。压缩算法再怎么优化也不会让程序更快。

3.3 还没做到的#

程序目前不输出读、算、写各自的分段吞吐，所以没法确定这 306 MiB/s 里各部分各占多少。上面 2,100 与 306 的 7 倍差距是两处独立测量的对比，不是同一份代码内部的分段结果；文件个数的影响也是推算，不是直接量出来的。

4.1 主表#

倍率以 v2.1.0 为基准。

4.2 每一步各自贡献了多少#

倍率本身没有单位。

两段的含义不同：

• v2.1.0 到 v2.2.0：v2.1.0 是流水线之前的串行版本。v2.2.0 把压缩和解压都改成了专职读线程、N 个计算工人、专职写线程的三段流水线，所以两边都变快。
• v2.2.0 到 v2.2.1：结构没再动，改的是算法本身，即 Huffman 编解码重写、AES 换成标准实现走硬件、开启 LTO，见 4.3 到 4.5 节。

主表最后一行的倍率同时回答了另一个问题：当前版本比起单线程版本，压缩吞吐是 9.78 倍，解压吞吐是 9.91 倍。

4.3 压缩与加密内核单独测#

最后一行是字节数，倍率 0.25 表示降到原来的四分之一。压缩内核的倍率是 7.46，但 4.2 节里 v2.2.0 到 v2.2.1 的实际倍率只有 1.89。差距的原因就是第 1 节说的那件事：实际跑的时候，压缩已经快过读写了，再快也体现不出来。

4.4 压缩内核是分几步改的#

编码侧每一步单独看：

此表用的是 8 MB 均匀数据，比真实数据更容易压缩，所以数字比 4.3 节高，两组不能直接比。

解码侧：

解码表的倍率以 v2.2.0 为基准。

4.5 加密为什么快了 20 倍#

v2.2.0 用的是自己写的 AES-CFB，纯软件计算，加密 62.8、解密 62.1 MiB/s。v2.2.1 改用 Windows 系统自带的标准 AES-128-CTR，直接走 CPU 的 AES-NI 硬件指令。选型时实测了系统提供的几种模式：

倍率以自研 AES-CFB 的 62.8 与 62.1 为基准。