当编译器对 UTF-8 产生分歧
When Compilers Disagree About UTF‑8
2006 年我开源了一个处理 UTF-8 字符串的 C++ 库。最近为了优化解码函数，我尝试利用 ASCII 字符天然符合 UTF-8 规则的特性进行加速。在 clang 编译器下，纯 ASCII 文本的解码吞吐量直接翻了三倍，混合文本也提升了 34%。然而，当我用 gcc 测试时，结果却令人意外：纯 ASCII 性能毫无提升，混合文本反而下降了 3-4%。通过对比生成的汇编代码，我发现 gcc 早已自动消除了 ASCII 分支中的冗余校验，而 clang 则没有。最终我调整了验证逻辑，让两者都获得了性能提升。这次经历让我深刻体会到，编译器优化行为千差万别，盲目优化可能适得其反。
编译器总是充满惊喜，但花些时间在优化上往往会有回报。
- kstenerud
实际上，你可以利用 SIMD 指令来检测高位清零的字节序列，从而实现对 ASCII 文本的批量复制，而无需逐字节循环。
另一个优化思路是利用这样一个事实：码点的使用往往围绕文本的语言呈现聚集效应。因此，如果你检测到使用了 3 字节编码，那么接下来大概率会持续遇到 3 字节编码，偶尔夹杂着 ASCII 或 emoji 码点。这为状态机设计打开了更多可能性。