-o0 是 callgrind 的硬性前提，因其依赖源码与指令一一对应、完整调用栈和调试符号来准确统计热点、映射行号及重建调用关系；-g、-o0、-fno-omit-frame-pointer 缺一不可。

不要开编译优化，必须用 -O0（或至少禁用内联、循环展开等干扰行为）。 否则 Callgrind / Cachegrind 报告的函数调用关系、热点行号、指令计数会严重失真，甚至完全不可读。

为什么 -O0 是 Callgrind 的硬性前提

Callgrind 通过插桩记录每条 VEX IR 指令的执行次数，再反向映射回源码行。一旦开启 -O2 或更高优化：

• 函数被内联后，main 里看不到 process_data() 的调用痕迹，Callgrind 只统计到 main 的指令，热点“消失”
• 循环被展开或向量化，原本 100 次迭代变成 4 条 SIMD 指令，for 循环体的“调用次数”不再反映真实逻辑频次
• 变量被提升到寄存器、临时对象被消除，--track-origins=yes 失效，Cachegrind 的缓存访问分析失去上下文

-g -O0 -fno-omit-frame-pointer 这三个参数缺一不可

它们共同保障 Callgrind 能准确关联指令、源码和调用栈：

Valgrind 3.23.0

Valgrind 3.23.0 官方历史源码发布包，适合旧项目兼容、复现历史内存检测结果、排查版本差异和在受支持 Unix-like 系统上自行构建。

下载

• -g：提供调试符号，否则 Callgrind 显示 ??? 而非函数名/行号
• -O0：禁用所有重排、合并、内联，保持源码结构与指令一一对应
• -fno-omit-frame-pointer：强制保留帧指针，让 Callgrind 能正确重建调用栈（尤其在深度递归或模板展开时）

Qt Creator 项目中若用 CMake，务必在 CMakeLists.txt 里显式设置：
set(CMAKE_BUILD_TYPE Debug)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g -O0 -fno-omit-frame-pointer")

性能影响大不大？要不要测 Release 版本？

Callgrind 本身会让程序慢 10–50 倍，这跟编译选项无关；但 -O0 会让原始程序变慢——这恰恰是你要分析的“未优化路径”。真实场景中：

• 先用 -O0 定位瓶颈（比如 std::string::append 占 40% 时间），再针对性改代码
• 改完后切回 -O2 编译，用 perf 或 gprof 验证线上效果——perf record -g ./app 不依赖调试符号，适合生产环境采样
• 永远别用 valgrind --tool=callgrind -O2 ./app：它既得不到准确调用图，又掩盖了 -O0 下暴露的低效逻辑

最常被忽略的一点：-fno-omit-frame-pointer 在现代 GCC/Clang 中默认关闭（尤其 -O2 以上），而 Callgrind 的调用图依赖它。漏掉这个参数，callgrind_annotate 输出的函数层级会塌缩成平铺，根本看不出谁调用了谁。