if/else 本身不慢，但分支预测失败会导致流水线冲刷，代价10–20周期；关键在分支是否可预测，可用__builtin_expect提示编译器优化布局，或用查表/位运算消除分支。

为什么 if/else 会拖慢 C++ 性能？

现代 CPU 依赖分支预测器猜测下一条指令路径。当 if 的条件结果高度不可预测（比如随机布尔值、哈希冲突标志、用户输入驱动的逻辑），预测失败会导致流水线冲刷，典型代价是 10–20 个周期。这不是“if 本身慢”，而是“预测错时代价高”。关键看分支是否**可预测**，而非是否用了 if。

用 __builtin_expect 显式提示编译器

GCC/Clang 支持内建函数告诉编译器哪个分支更可能走，帮助生成更优的汇编（如把冷路径挪到主流程之外）。注意：它不改变运行时行为，只影响代码布局和预测 hint。

if (__builtin_expect(ptr != nullptr, 1)) {
    return ptr->value;
} else {
    return fallback_value; // 编译器知道这行极少执行
}

• __builtin_expect(expr, expected_value)：第二个参数是程序员声称的“最可能取值”
• 常用写法：__builtin_expect(!!cond, 1) 表示 cond 为真概率高；__builtin_expect(!!cond, 0) 表示为假概率高
• 仅对 GCC/Clang 有效；MSVC 用 __assume(0) 或 [[likely]]/[[unlikely]]（C++20）
• 过度使用反而干扰编译器自动分析，只在 hot path 上明确有偏斜分布的分支加

用查表（LUT）或位运算替代简单条件判断

当条件是小范围整数（如枚举、状态码 0–7），且分支体很短（比如返回不同常量、设置不同 bit），查表或位运算往往比分支更快，也完全消除预测开销。

// 原始 if 链
if (mode == 0) return 1;
else if (mode == 1) return 2;
else if (mode == 2) return 4;
else return 8;

// 替代：静态数组查表（编译期确定大小）
static constexpr int lut[] = {1, 2, 4, 8};
return (mode < 4) ? lut[mode] : lut[3]; // 加个边界检查，或确保 mode 已验证

• 查表适用于分支逻辑无副作用、输入域小且密集的场景
• 用 constexpr 数组保证零运行时代价；避免动态分配或大数组导致 cache miss
• 位运算更适合布尔组合，例如：(a 直接映射到 3-bit 状态，再查表
• 别为了“去 if”而引入复杂计算——要测，不是所有查表都比分支快

结构体对齐与数据局部性比分支优化更重要

很多开发者花时间调 __builtin_expect，却忽略更重的性能瓶颈：缓存未命中。如果 if 判断依赖分散在内存各处的字段（比如遍历链表时检查每个节点的 flag），那分支预测开销根本排不上号。

立即学习“C++免费学习笔记（深入）”；

• 优先把热字段打包进同一 cacheline（如用 struct 聚合相关 flag + counter）
• 用 AoS（Array of Structs）还是 SoA（Struct of Arrays）取决于访问模式：批量处理同类型字段时 SoA 更友好
• 确认你真在 hot path 上优化——先用 perf / VTune 抓到 branch-misses 占比 > 5%，再动手
• C++20 的 [[likely]] 和 [[unlikely]] 更可读，但效果等价于 __builtin_expect，别以为加了就一定快

真正难的是判断“这个分支到底 predict 不predict”——得看数据分布，不是看代码长得像不像规律。测不到分布，所有提示都是赌运气。