应使用--fn-skip正则过滤测试框架函数，并配合--toggle-collect精准开启目标函数统计；编译需加-g和禁用内联以确保函数名可见；callgrind仅统计cpu指令，i/o或锁等待需换用perf或ebpf。
直接跑 valgrind --tool=callgrind 会把整个测试框架（比如 Google Test、Catch2）的初始化、断言宏展开、异常捕获逻辑全塞进报告里，真正想看的业务函数调用占比可能压根排不进前 20。必须过滤掉测试框架干扰，才能定位真实热点。
怎么让 Callgrind 只统计被测函数和核心逻辑
Callgrind 默认记录所有指令执行，包括 main() 入口、gtest 的 InitGoogleTest()、EXPECT_EQ 展开后的模板代码、甚至 libc 的 malloc 调用。这些不是你要优化的对象。
- 用
--dump-instr=yes+--collect-jumps=yes不必要，反而增大输出体积；默认模式已足够分析函数级耗时 - 关键加
--fn-skip=.*gtest.* --fn-skip=.*test_.*（正则跳过 gtest 相关函数），但注意：glibc 或 libstdc++ 中的__cxxabiv1::__cxa_throw仍会被计入——如果你的测试大量抛异常，这部分开销会虚高 - 更稳妥的是用
--toggle-collect=YourActualFunctionName，只对明确要分析的函数开启计数，比如--toggle-collect=MyAlgorithm::process，其他一概忽略
为什么 callgrind_annotate 输出里看不到你的测试用例函数名
常见原因是编译时没带调试信息或函数被内联了。Callgrind 依赖 DWARF 符号表做函数名映射，而 g++ -O2 默认会内联小函数，导致 callgrind_annotate 只显示 ??? 或上级调用者。
- 编译测试可执行文件时必须加
-g -O0或至少-g -O1（-O1内联较少，保留大部分函数边界） - 如果必须用
-O2，加-fno-inline -fno-inline-small-functions强制禁用内联，否则callgrind_annotate看不到实际函数名 -
callgrind_annotate默认按“指令数”排序，但你想看“耗时”，得确认你用的是--simulate-cache=yes模式，否则 cache miss 模拟不启用，数据不代表真实 CPU 延迟
怎么把单个测试用例从整个 test binary 中分离出来跑
Google Test 支持通过 --gtest_filter 运行单个用例，但 Callgrind 会照常加载全部静态初始化逻辑。这不是 bug，是设计使然——你无法绕过 test binary 的启动开销，只能让它最小化。
- 命令示例：
valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes --fn-skip='.*gtest.*' ./my_tests --gtest_filter=MySuite.MyCase - 别用
--log-file=callgrind.out，Callgrind 默认生成callgrind.out.<pid></pid>，多个测试并行跑时不会覆盖 - 运行完立刻执行
callgrind_annotate callgrind.out.* | head -n 50，避免被框架函数刷屏；重点关注 “Ir”（指令数）列中你自己的函数名是否出现，且占比 >5%
最易被忽略的一点：Callgrind 统计的是模拟指令数，不是 wall-clock 时间。如果你的函数主要卡在系统调用（比如 read()、sleep()）或锁等待上，Callgrind 报告里几乎不体现——它只数 CPU 执行的指令。这种场景该换 perf record -e cycles,instructions,cache-misses 或 Linux eBPF 工具。
