GitHub 搜索优化：为何不停早更快
Don't stop early: Case-folding source code at memory speed
在 GitHub 的 Blackbird 代码搜索引擎中，处理 480TB 源码的 case folding 操作至关重要。我们发现一个反直觉的真相：在 ASCII 快速路径上，移除“遇到非 ASCII 字节就提前退出”的优化，反而能实现内存带宽级别的性能。通过消除循环中的分支判断，让编译器进行向量化处理，吞吐量从 3 GiB/s 飙升至 45 GiB/s。文章还探讨了如何避免堆内存分配，以及利用稀疏表结构让 Unicode 折叠同样高效。
在标量代码中，无分支实现反而是一种性能恶化。
HN 评论区
34- lukasgelbmann
> 我们主要处理源代码，因此我们折叠的文本绝大多数是 ASCII，让它在内存速度下运行是我们能做的最重要的事。其他一切只需确保罕见的非 ASCII 路径不会破坏这一点。
半相关话题：我注意到许多通过编程代理使用的 LLM（工作中用我的 CoPilot 账户的 ChatGPT 和 Claude，家里用 pi.dev 上的 DeepSeek 4 和 ChatGPT）似乎特别喜欢用 Unicode/Emoji 字符来表示箭头（比如测试值范围）、叉号和勾号（用于测试注释中的通过/失败），而不是纯 ASCII。据我所知，代码库几乎全是 ASCII 字符，尽管它们是 UTF-8 文件。
我目前还没用代理来写代码（只做代码审查、编写示例原型然后复制片段，以及帮忙设计测试），但我很快可能会开始用。我肯定可以提示它们不要这么做，但有人注意到这个问题吗？我想知道如果非 ASCII 输出变得越来越普遍，这会不会随时间改变它们的行为？
- claudetard
这是很好的技术内容，但很明显是 AI 写的。
- inigyou
太长不看版：他们通过自动向量化，用更多 SIMD 实现了大小写折叠。
> 几乎每个折叠操作都保持 UTF-8 长度或缩短它，但有两个例外会变长——U+023A (Ⱥ) 和 U+023E (Ɀ) 各占 2 字节，却折叠成 3 字节字符 (ⱥ, ɀ)
解决办法是反过来：把 ⱥ 折叠成 Ⱥ，而不是反过来。搜索索引将不再只包含小写字符，但这从来都不是问题。