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”——得看数据分布，不是看代码长得像不像规律。测不到分布，所有提示都是赌运气。
