测量思路#

SFC 的归档流程包含文件读取、压缩或加密、归档写入；解档流程则从归档读取数据，执行解密或解码，再创建并写出文件。三段可以并行重叠，稳态吞吐通常受供给能力较弱的阶段约束。增加计算工人能提高计算侧并行度，但文件枚举、逐文件读写和任务调度仍会参与完整流程。

因此，测试分成三类：用内存中的数据观察计算工人数变化；用不同文件大小和数量比较完整流程；单独测量磁盘与编解码内核作为参照。它们分别回答计算能否扩展、实际文件集的处理速度，以及单项操作的大致能力。

测试条件#

测试机器使用 AMD Ryzen 7 8845H，8 个物理核、16 个逻辑处理器和 23.3 GB 内存。单文件顺序写入测得 2880 MiB/s，顺序读取测得 6775 MiB/s。

内核吞吐来自单线程、每块 8 MiB 的独立测量，多次运行取最快值。cpu_corpus 用于观察工人数伸缩，完整流程结果则包含文件系统、目录处理、归档操作和磁盘 I/O。

计算侧伸缩#

cpu_corpus 的工人数对照如下：

从 1 个工人增加到 16 个，吞吐约为原来的 6 倍；从 8 个增加到 16 个，吞吐增加约 20%。这组数据展示的是内存数据上的计算扩展，不等同于文件树的端到端收益。

在 NCIEP 文件树上的另一组对照中，1 个和 16 个工人各测两次，表中为重复测量的平均值：

压缩吞吐从 8 个工人到 16 个工人没有继续增加，解压则仍有提升。完整文件树包含大量独立文件，其目录处理、读写和输出开销会影响工人数量带来的收益。

文件规模与 I/O#

以下两组完整流程都使用相同的工人数设置：

相同工人数变化在两个场景中的收益不同。大文件场景有较多连续数据可供计算工人处理；PackOnly 仍需枚举并读写大量文件，但不执行压缩或加密。这组差异说明文件数量和处理路径也会影响吞吐。

单独的磁盘与文件枚举测量如下：

单文件顺序读写描述连续 I/O 的能力，多文件测试则包含目录遍历、逐文件打开和归档处理。前者不能直接代表后者的速度；排查真实工作负载时，需要同时保留文件总量和单文件大小分布。

编解码内核#

单线程、每块 8 MiB 的独立内核测量结果如下：

Huffman 数据块携带 258 字节码长表。内核测量不包含目录枚举、块调度、文件创建和归档 I/O，因此不能据此直接推算完整流程速度。端到端流程还会受到阶段供给、文件数量和数据压缩率的共同影响。

完整流程与测量边界#

对 13.47 GiB、45,390 个文件执行完整流程，测得压缩吞吐 254.3 MiB/s、解压吞吐 325.1 MiB/s。这组结果用于描述该输入和该次运行条件下的整体链路，与前面的工人数对照分别记录。

解压需要创建大量文件，重复结果波动更明显。16 个工人的两次解压测量为 275.6 和 336.6 MiB/s，因此单次完整流程结果应结合重复运行观察，不宜把小幅差异解释为算法变化。

这些对照表明，内核速度、连续磁盘吞吐和真实文件树吞吐衡量的是不同部分。判断瓶颈时，应固定输入、模式和运行条件，每轮改变一个主要因素，并把计算侧数据与完整读、算、写结果放在一起看。

项目介绍：SFC | 开发日志：SFC | 性能优化方法论