callgrind不标记“异常慢的分支”，只统计指令执行次数和调用关系；所谓“慢”需结合callgrind_annotate输出与代码逻辑人工识别，因其无语义判断能力，仅反映底层abi函数（如__cxa_throw）的累积开销。
Callgrind 本身不直接标记“异常慢的分支”，它只记录函数调用频次和指令开销；所谓“异常慢”，必须靠你结合 callgrind_annotate 输出 + 代码逻辑人工识别。
为什么 callgrind 不会标出“throw 很慢”这种结论
Callgrind 模拟 CPU 执行，统计每条指令的执行次数（Ir）和函数调用关系。它不会做语义判断——比如它不知道 throw 是异常抛出，也不知道 catch 是异常捕获。它只看到：__cxa_throw 这个符号被调用了多少次、花了多少指令周期。
所以你看到的“慢”，其实是底层运行时开销（如栈展开、类型匹配、析构调用）在指令层的累积体现，不是语法层面的“分支慢”。
- 异常路径的开销集中在
__cxa_throw、__cxa_begin_catch、__cxa_end_catch等 ABI 符号上，不是你的fun2_throwError函数本身慢 - 如果你没编译带
-g，callgrind_annotate只能显示汇编或符号名，看不到源码行对应关系 - Release 模式下编译器可能内联掉简单函数，导致调用图失真；建议用
-O0 -g跑 Callgrind
怎么用 callgrind_annotate 定位 throw 的真实开销
先生成 profile 文件：
valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes ./your_program
默认输出为 callgrind.out.PID。然后用 callgrind_annotate 解析：
callgrind_annotate --auto=yes --show=I1,D1,LL --threshold=0.1 callgrind.out.PID
重点关注以下几列：
-
Ir（Instruction reads）：越高说明该函数/行执行指令越多，异常路径通常在此暴增 - 函数名含
__cxa_或std::throw_with_nested的条目，就是异常机制的实现代价 - 你的自定义函数（如
fun2_throwError）如果 Ir 极低但调用了高 Ir 的__cxa_throw，说明开销不在你代码里，而在抛出瞬间
对比状态码和 throw 的性能差异要控制变量
别只比“循环调用 10 万次”，得确保两段逻辑真正等价：
- 状态码路径必须包含同样量级的错误处理分支（比如 if (ret == -1) { ... }），否则不公平
- throw 路径要 catch 住并做等效处理（哪怕空 catch），否则
std::terminate会提前终止，测不到真实开销 - 避免在
catch块里做 I/O（如std::cerr ），这会污染性能数据 - 用
chrono::high_resolution_clock测微秒级耗时没问题，但 Callgrind 的模拟开销比真实运行高 10–50 倍，两者数值不能直接比，只能看相对比例
容易忽略的陷阱：优化级别和异常开关
gcc/clang 默认开启异常支持（-fexceptions），但如果你加了 -fno-exceptions，throw 会直接编译失败；而即使开了，某些优化（如 -O2）会让 Callgrind 统计失真。
- 务必用
g++ -O0 -g -fexceptions编译，保证符号完整、无内联、异常可用 - 检查你的程序是否链接了 libstdc++ 的异常运行时（
nm -C your_binary | grep cxa_throw应有输出） - Callgrind 不分析模板实例化爆炸，如果异常类型是复杂模板类，
__cxa_throw的调用开销可能被低估
真正难的是区分“这里慢是因为异常机制本身重”，还是“这里慢是因为我 catch 里做了太多事”。Callgrind 给你的是指令证据，不是归因结论——得你自己对照符号、源码和 ABI 文档交叉验证。
