vtune分析需保留调试符号：编译必须加-g（至少-gline-tables-only）和-o2/o3，禁用-fvisibility=hidden与-lto；命令行vtune -collect hotspots最高效，开启stack-collection可查看完整调用栈，函数名需demangle解析。
直接上手就能看到热点函数，但必须先让编译器保留符号和调试信息，否则 vtune-gui 只能显示地址，看不到函数名。
编译时必须加 -g -O2（或 -O3），禁用 -fvisibility=hidden 会丢符号
VTune 不是黑盒采样工具，它依赖 DWARF 符号定位源码行。常见错误是用生产构建参数（比如 -O3 -DNDEBUG -fvisibility=hidden）直接跑分析，结果 vtune-gui 里全是 ??? 或十六进制地址。
-
-g必须存在，哪怕只加-gline-tables-only也能满足基本函数级定位 -
-O2或-O3没问题，VTune 能正确映射优化后的指令到原始源码行（前提是没内联掉） - 如果用了
-fvisibility=hidden，又没显式用__attribute__((visibility("default")))标记导出函数，vtune就无法关联动态符号表，导致热点函数名丢失 - 不建议用
-flto+vtune混合使用——LTO 会重排/合并函数，DWARF 行号映射容易错位，优先关掉 LTO 做 profiling
vtune 命令行快速抓热点：用 hotspots 分析类型最稳
图形界面容易卡在配置页，而命令行几秒就能出结果。对 C++ 程序，hotspots 是最直接的起点，它采样 CPU cycles 并回溯调用栈。
- 基础命令：
vtune -collect hotspots -result-dir ./r001hs ./my_app -- arg1 arg2 -
-result-dir必须指定，否则默认写进/tmp，容易被清理 - 如果程序启动后很快退出，加
-duration 30强制采集 30 秒（即使进程已结束） - 避免用
microarchitecture-exploration初筛——它开销大、结果字段多，新手易看晕；先用hotspots定位 top3 函数，再针对性深挖
GUI 里看不清调用栈？检查是否启用了 stack-collection
默认 hotspots 分析只记录 leaf 函数（最底层那个），看不到谁调了它。C++ 模板展开、STL 迭代器嵌套、RAII 析构链都藏在调用栈里。
- 命令行补参数：
vtune -collect hotspots -knob stack-collection=true -result-dir ./r002hs ./my_app - GUI 中，在
Configure Analysis > Hotspots > Advanced > Stack Collection打钩 - 注意：开启后数据量翻倍，远程采集或低内存机器慎用；若只关心循环体内部，可关掉
- 如果调用栈里出现大量
std::符号但看不清用户代码，说明编译时没带-g或 STL 是系统预编译版本（无调试信息），此时只能靠函数名 + 地址偏移反推
模板函数和内联函数在 VTune 里怎么识别
VTune 显示的函数名是编译器生成的 mangled name，比如 _ZSt4copyISt15istream_iteratorIcSt18basic_istreamIcSt11char_traitsIcEEES3_ET0_T_S7_S6_，不是 std::copy。
- GUI 中右键函数名 →
Demangle Symbol可转成可读形式（但不会自动展开模板实参） - 命令行结果用
vtune -report hotspots -r ./r001hs | c++filt管道处理，批量解码 - 内联函数不会单独列出，它的耗时已合并进调用者；想确认是否内联，得看源码旁的汇编视图（
Assembly标签页）中是否有call指令 - 若发现某个模板实例（如
vector<double>::push_back</double>）热点极高，但你改的是vector<int></int>，说明实际压入的是 double——VTune 不骗人，得回头查类型推导逻辑
真正容易被忽略的点是：VTune 默认按“CPU 时间”排序，但 C++ 程序常卡在锁、IO、内存分配上。如果 hotspots 里 top 函数看着不烫，先切到 Threading 或 Memory Consumption 分析类型，别死守一个视图。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
