【当编译器对 UTF-8 产生不同见解】2006 年夏天有人启动了一个用于处理 UTF - 8 字符串的开源 C 库。当时希望它具备可移植性且能与 STL 良好协作不过未在优化方面投入过多精力。【重新审视与函数优化】最近此人开始撰写关于 UTF - 8 解码的文章因此花更多时间重新审视该库的内部实现并决定优化一个用于解码 UTF - 8 编码代码点的函数。这个函数逻辑直接根据前导字节的值确定序列长度再依据长度从字节中提取合适的位域来构建代码点的值。成功解码后还会进行两项检查若都通过则返回成功状态并将迭代器移至下一个序列。【优化机会与新代码】这里存在优化机会因为 ASCII 字符能轻松满足所有 UTF - 8 有效性要求。若前导字节的最高位为 0就是“ASCII 字符”其值范围在 [U0000, U007F] 内始终有效只需零扩展就能得到代码点。优化后的代码在处理纯 ASCII 字符时做了特殊处理。【测试结果Clang 与 GCC 的差异】原本期望在处理纯 ASCII 字符串序列时能看到明显的性能提升对混合 ASCII/非 ASCII 字符串的影响较小。使用 Clang 18.1.3 进行测试的结果超出预期对于纯 ASCII 文本UTF - 8 解码吞吐量提升了两倍即便对于混合文本提升幅度也约为 34%。然而用 GCC 测试时在处理 ASCII 文本时完全没有性能差异提升幅度为零对于大量混合文本吞吐量始终下降了 3 - 4%。【深入研究汇编代码】为探究原因深入研究了生成的汇编代码。使用 g 编译原始版本处理 ASCII 代码点时编译器能判断检查总是会通过直接移除了验证检查优化并未改变生成的代码。而 Clang 并未消除代码点有效性检查优化后代码有明显变化这就解释了为什么 Clang 的性能有如此大的提升。【更大改动与最终结论】最终进行了一个更大的改动增强了 get_sequence_* 函数使其能够内联执行验证。这样既保留了 Clang 的所有性能提升又让 GCC 在处理混合文本时性能提升了 15 - 20%对于纯 ASCII 文本性能没有差异。那么从这个故事中我们能得到什么启示呢编译器很复杂但花些时间进行优化是否真的值得呢
