为什么“打开 O3”还不够

大型 C++ 服务的热点跨模块分散，单文件优化难以奏效。LTO 能打通跨 TU 优化，PGO 能把优化预算聚焦在真实热路径。

推荐流程

  1. 基线版本：记录 p50/p99、CPU、指令数、缓存 miss。
  2. LTO 版本：先验证链接时间与二进制体积变化。
  3. PGO 训练：必须使用“接近线上”的请求分布。
  4. 组合验证：LTO + PGO 与基线做 A/B。

CMake 关键配置示例

# LTO
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)

# PGO 两阶段
# 1) -fprofile-generate
# 2) -fprofile-use -fprofile-correction

最常见的误区

  • 用单一压测脚本训练 PGO，导致优化偏科。
  • 只看吞吐，不看长尾延迟和抖动。
  • 忽略符号变化对排障工具链（perf、addr2line）的影响。

回归防线

  • 增加“训练集漂移”检测：训练流量和线上流量偏差超阈值就拒绝发布。
  • 将“优化收益”拆解到函数级，防止偶然抖动误判。
  • 为 PGO 单独维护回退开关和构建产物。

小结

LTO/PGO 是生产力工具，不是玄学加速按钮。只有接入真实流量画像和回归防线，优化收益才可持续。