PGO

为什么“打开 O3”还不够 大型 C++ 服务的热点跨模块分散，单文件优化难以奏效。LTO 能打通跨 TU 优化，PGO 能把优化预算聚焦在真实热路径。 推荐流程 基线版本：记录 p50/p99、CPU、指令数、缓存 miss。 LTO 版本：先验证链接时间与二进制体积变化。 PGO 训练：必须使用“接近线上”的请求分布。 组合验证：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 是生产力工具，不是玄学加速按钮。只有接入真实流量画像和回归防线，优化收益才可持续。