代码搜索需要处理海量文本。即使“把 ASCII 大写字母转成小写”看起来只是一个微不足道的步骤，只要它要扫描索引中的每一个字节，就会直接影响整条搜索链路的吞吐量。GitHub 的实践表明，通过无分支循环和字节空间算术，单核大小写折叠可以超过 45 GiB/s，性能开始接近内存子系统本身的上限。
慢的往往不是加法，而是控制流
最直观的 ASCII 大小写折叠通常写成这样：
if (c >= 'A' && c <= 'Z') {
c += 'a' - 'A';
}
这段代码语义正确，但它把每个输入字节都变成了一次条件判断。源码中的大小写分布不稳定：关键字可能是小写，常量和类型名可能包含大写，字符串与二进制片段则更加不可预测。分支预测一旦失误，处理器流水线就要付出代价。
更重要的是，复杂的逐字节控制流会妨碍编译器进行自动向量化。现代 CPU 可以用一条 SIMD 指令并行处理多个字节，但前提是循环足够规则：每次迭代执行相同的工作、没有数据相关跳转，并且内存访问连续。
无分支写法可以把“是否为大写字母”变成一个整数掩码：
unsigned int is_upper = (unsigned int)(c - 'A') <= ('Z' - 'A');
c = (unsigned char)(c + is_upper * ('a' - 'A'));
当 c 位于 A 到 Z 之间时，is_upper 为 1，于是加上 32；否则乘积为 0，字节保持不变。这里仍然有比较操作，但不需要根据数据跳转。优化编译器通常可以将它降为比较、掩码或向量指令。
“不要提前退出”是在保护热循环
很多字符串算法习惯尽早返回：发现目标、遇到不匹配或确认没有转换必要后，就立即停止。这对只处理少量数据的函数可能有效，但对批量源码扫描未必合算。
提前退出会引入数据依赖的循环长度和额外分支。处理器难以提前安排后续指令，编译器也更难把循环展开或向量化。相反，一个从 0 到 n、无条件访问每个字节的循环，具有几个明显优势：
- 读取和写入都是连续的，硬件预取器容易跟上。
- 每次迭代结构一致，编译器更容易自动向量化。
- 性能不再强烈依赖源码内容和大小写分布。
- 数据规模足够大时，瓶颈会从指令与分支转移到内存带宽。
这并不意味着所有算法都应禁止提前退出。对于短字符串比较，首字节不同后立即返回仍然合理。这里的关键边界是：任务本来就需要生成完整的折叠结果，或者后续步骤大概率会消费整个缓冲区。此时，稳定地扫完所有字节通常更适合现代 CPU。
可以这样实践：让编译器向量化 ASCII 折叠
下面是一个可复制运行的 C 示例。它只折叠 ASCII A-Z，不会改动 UTF-8 多字节序列中的非 ASCII 字节。restrict 告诉编译器输入与输出不重叠，有助于消除别名检查；如果业务需要原地转换，应改用单缓冲区版本。
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
static void fold_ascii(const uint8_t *restrict src,
uint8_t *restrict dst,
size_t len) {
for (size_t i = 0; i < len; ++i) {
uint8_t c = src[i];
unsigned int upper =
(unsigned int)((unsigned int)c - (unsigned int)'A') <=
(unsigned int)('Z' - 'A');
dst[i] = (uint8_t)(c + upper * (unsigned int)('a' - 'A'));
}
}
static double seconds(void) {
struct timespec ts;
timespec_get(&ts, TIME_UTC);
return (double)ts.tv_sec + (double)ts.tv_nsec / 1e9;
}
int main(void) {
const size_t size = 256u * 1024u * 1024u;
const int rounds = 8;
uint8_t *src = malloc(size);
uint8_t *dst = malloc(size);
if (src == NULL || dst == NULL) {
fprintf(stderr, "allocation failed\n");
free(src);
free(dst);
return 1;
}
const char sample[] = "GitHub CODE Search: HTTPServer_v2\n";
for (size_t i = 0; i < size; ++i) {
src[i] = (uint8_t)sample[i % (sizeof sample - 1)];
}
fold_ascii(src, dst, size);
double begin = seconds();
for (int i = 0; i < rounds; ++i) {
fold_ascii(src, dst, size);
}
double elapsed = seconds() - begin;
unsigned long checksum = 0;
for (size_t i = 0; i < size; i += 4096) {
checksum += dst[i];
}
double gib = (double)size * rounds / (1024.0 * 1024.0 * 1024.0);
printf("throughput: %.2f GiB/s, checksum: %lu\n",
gib / elapsed, checksum);
free(dst);
free(src);
return 0;
}
在 Linux 或 macOS 上可以这样编译：
cc -O3 -march=native -std=c11 -Wall -Wextra fold.c -o fold
./fold
这里的吞吐量按读取的输入字节计算。如果希望统计读写总流量，应将结果乘以二。-march=native 允许编译器使用当前机器支持的 SIMD 指令，因此生成的二进制不一定适合分发到其他 CPU。
还可以查看编译器是否完成了向量化。GCC 可以使用：
cc -O3 -march=native -std=c11 \
-fopt-info-vec-optimized -fopt-info-vec-missed \
fold.c -o fold
Clang 可以使用：
clang -O3 -march=native -std=c11 \
-Rpass=loop-vectorize -Rpass-missed=loop-vectorize \
fold.c -o fold
不要只根据源代码里“没有 if”就断定机器码没有分支。应结合向量化报告、反汇编和真实性能计数器检查最终结果。在 Linux 上，可以进一步运行：
perf stat -e cycles,instructions,branches,branch-misses,cache-misses ./fold
ASCII 快路径不等于 Unicode 大小写转换
代码搜索中的源码大部分可能由 ASCII 构成，但“大小写折叠”在 Unicode 语境下远不只是加 32。某些字符的折叠结果长度会变化，也可能涉及区域和规范化规则。上面的算法只适合以下场景：
- 搜索语义明确规定仅对 ASCII 大小写不敏感。
- 非 ASCII 字节必须原样保留。
- 系统另有 Unicode 慢路径或规范化阶段。
如果产品承诺完整 Unicode case folding，就应使用经过验证的 Unicode 数据表或库，并把 ASCII 无分支循环作为快路径，而不是拿它替代完整语义。还要分别测试 ASCII、混合 UTF-8、极短输入和超大缓冲区，避免基准只覆盖最有利的数据形态。
落地时检查这几件事
将这种优化引入生产系统前，应先确认算法确实位于性能热点，并固定大小写折叠的语义边界。随后比较有分支与无分支版本，查看编译器是否向量化，同时在目标 CPU 上测量吞吐量、分支失误和内存带宽。
超过 45 GiB/s 的核心经验并不是某条神奇指令，而是把循环整理成处理器最容易执行的形状：连续访问内存，对每个字节执行相同算术，不让内容决定控制流。当计算成本降到足够低时，大小写折叠就不再是一串字符判断，而会变成一次接近内存速度的流式搬运与变换。