C++ 性能分析全景指南：从工具链到方法论
C++ 性能分析全景指南：从工具链到方法论 不要凭直觉猜瓶颈——人的直觉在性能问题上错误率极高。先量测，再优化。 写在前面 性能优化是 C++ 程序员的核心竞争力之一。但"性能优化"这四个字太大了——从微架构级的 cache line 对齐，到宏观的算法复杂度选择，中间跨越了多个抽象层次。 这篇文章不是某个工具的使用教程，而是试图建立一套完整的性能分析知识框架：遇到性能问题时，你该用什么工具、看什么指标、按什么思路排查。全文分为九个部分： 核心思维 CPU Profiling 内存分析 编译优化分析 Benchmark 编写 并发与锁分析 Sanitizer 全家桶 优化决策方法论 工具选择与学习路线 一、核心思维 1.1 性能问题的三种类型 所有性能问题，本质上只有三类： 类型 表现 典型原因 CPU-bound CPU 利用率高，但吞吐上不去 算法复杂度高、分支预测失败、指令级并行度低 Memory-bound CPU 利用率不高（在等数据），IPC 低 缓存未命中、TLB miss、false sharing、频繁堆分配 I/O-bound CPU 几乎空闲，程序却很慢 磁盘读写、网络等待、锁竞争（广义 I/O） 判断当前程序属于哪一类，是性能分析的第一步。用错了工具，你会在错误的方向上浪费大量时间。 1.2 Amdahl 定律的启示 优化一个占总耗时 5% 的函数，即使你把它优化到 0，整体也只快 5%。但优化一个占 60% 的函数，哪怕只快 20%，整体就快 12%。 永远先找大头。这就是为什么 profiling 必须走在优化前面。 1.3 量测的四条铁律 在接近生产环境的条件下量测——Debug 模式的热点分布和 Release 完全不同 量测时关闭无关进程——CPU 频率调节（turbo boost / power saving）会干扰结果 多次量测取统计值——单次运行的噪声太大，至少跑 3 次取中位数 量测前后只改一个变量——否则你不知道是哪个改动起了作用 二、CPU Profiling CPU 剖析是性能分析的基础。根据实现方式不同，分为采样式和插桩式两大类。 ...