性能分析工具——找到真正的瓶颈 / Performance Analysis Tools for Finding Real Bottlenecks
📅 创建时间：2026-06-02 🏷️ 标签：#HPC #性能分析 #WPR #WPA #VTune #nsys #ncu #PyTorchProfiler 📚 前置知识：[[06-cuda-optimization]]（CUDA 优化） [[10-dl-training-optimization]]（训练优化） 📚 相关知识：[[05-cuda-kernel-and-memory]]（内存管理）
先抓住直觉
Profiler 像医院检查：先判断问题发生在整条训练流水线、某个 Kernel，还是内存分配，再选择对应工具。指标不是分数；“越高越好”通常不成立，关键是它能否解释实际耗时。
- 必须理解：先建立基线；从总时间逐层下钻；一次只验证一个假设。
- 用到再查：
nsys、ncu和 PyTorch Profiler 的命令参数。 - 最小流程：复现 → 测量 → 定位最大耗时 → 提出假设 → 修改 → 用同一基线复测。
场景：优化了半天，为什么还是没快？
┌─────────────────────────────────────────────────────────────┐
│ │
│ 你做了一堆优化： │
│ ✅ 合并内存访问 │
│ ✅ 使用共享内存 │
│ ✅ 优化了 block 大小 │
│ │
│ 自测结果： │
│ 优化前：15 GFLOPS │
│ 优化后：18 GFLOPS │
│ │
│ 提升 20%，但离 A100 的 156 TFLOPS 还差很远！ │
│ │
│ 瓶颈到底在哪里？ │
│ → 盲目优化 = 浪费时间 │
│ → 必须用工具定位瓶颈！ │
│ │
└─────────────────────────────────────────────────────────────┘第1节：性能分析工具全景
┌─────────────────────────────────────────────────────────────┐
│ NVIDIA 性能分析工具 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Nsight Systems（nsys）： │
│ 定位：系统级 timeline 分析 │
│ 看什么：CPU-GPU 传输时间、kernel 执行顺序、并行度 │
│ 类比：航空调度中心，看整个机场的运行 │
│ │
│ Nsight Compute（ncu）： │
│ 定位：kernel 级别性能分析 │
│ 看什么：SM 利用率、内存带宽、warp 效率、瓶颈类型 │
│ 类比：单架飞机黑匣子，看具体故障原因 │
│ │
│ PyTorch Profiler： │
│ 定位：深度学习训练性能分析 │
│ 看什么：每层的耗时、CPU-GPU 传输、内存使用 │
│ │
│ VTune（Intel）： │
│ 定位：CPU 性能分析 │
│ 看什么：CPU 利用率、OpenMP 效率、SIMD 利用率 │
│ │
└─────────────────────────────────────────────────────────────┘第2节：WPR——Windows 事件采集器
Windows Performance Recorder（WPR）基于 ETW 记录系统和应用事件。 它负责采集，不负责完成最终归因。
WPR 的核心概念是 Profile。 Profile 定义要启用的 Provider、Kernel Event、Stack 和缓冲策略。
内置 Resource Profile 可以覆盖：
- CPU Usage；
- Disk I/O；
- File I/O；
- Registry I/O；
- Networking I/O；
- Heap Usage；
- GPU Activity；
- Power；
- Responsiveness。
实际可用 Profile 以本机版本为准：
wpr -profiles
wpr -profiledetails GeneralProfile基本采集流程
# 查看当前状态
wpr -status
# 启动通用采集，文件模式适合受控复现
wpr -start GeneralProfile -filemode
# 执行需要复现的操作
.\MyApplication.exe
# 停止并保存 ETL
wpr -stop .\results\slow-operation.etl
# 取消错误启动的会话
wpr -cancelProfile 名称和参数应先通过 wpr -profiles 与 wpr -help 核对。 不同 Windows/WPT 版本可能提供不同内置项。
Memory Mode 与 File Mode
Memory Mode 使用内存中的循环缓冲区。 适合问题偶发、无法准确预知开始时间的场景。
start circular trace
-> wait for symptom
-> stop immediately after symptom
-> save recent windowFile Mode 持续把事件写入文件。 适合可控、时间较短的回归复现。
长时间 File Mode 会产生大文件并引入 I/O。 采集本身可能影响被测系统，需要控制窗口与 Provider 数量。
Light 与 Verbose
Light 记录较少事件，开销和文件更小。 Verbose 提供更多细节，但可能提高采集开销。
先用最小足够 Profile。 只有现有证据无法回答问题时，再增加 Provider 和 Stack。
自定义 WPRP
应用有自定义 ETW Provider 时，可以编写 .wprp XML Profile。
自定义 Profile 需要定义：
- Collector；
- Buffer 大小与数量；
- Event Provider；
- Keyword 和 Level；
- Stack；
- Logging Mode；
- Scenario。
缓冲区太小会增加 Flush 和丢事件风险。 Provider 太多会放大数据量与扰动。
采集窗口
WPR 采集应围绕可识别事件：
start trace
-> idle baseline
-> marker: operation begin
-> reproduce slow operation
-> marker: operation end
-> stop trace应用可写 ETW Marker 或使用 WPR Marker，让 WPA 中更容易定位时间段。
WPR 常见错误
- 未以足够权限启用某些系统 Profile；
- 上次采集未停止；
- ETL 写入目录没有空间；
- 采集时间过长；
- 开启过多 Stack；
- 复现步骤没有时间标记；
- 只采 CPU，却实际是磁盘或网络问题；
- 忘记保存符号对应的构建。
第3节：WPA——Windows 时间线与关键路径分析
Windows Performance Analyzer（WPA）打开 WPR 生成的 ETL。 它提供图、时间线和可 Pivot 的明细表。
WPA 的基本操作逻辑：
open ETL
-> locate symptom interval
-> add relevant graph
-> filter process / thread
-> choose table preset
-> add stack columns
-> follow critical path
-> form hypothesis不要一打开 ETL 就展开所有图。 先明确用户看到的时间段和进程。
CPU Usage (Sampled)
Sampled 通过周期性采样指令地址观察 On-CPU 热点。
它回答：
- 哪个进程消耗 CPU；
- 哪个线程消耗 CPU；
- 哪些模块和函数占样本；
- 热调用路径是什么；
- CPU 工作如何分布到逻辑处理器。
常用表格分组：
Process
-> Thread
-> Stack
-> WeightWeight 表示样本代表的时间权重。 横向百分比不是事件顺序。
CPU Usage (Precise)
Precise 基于上下文切换和线程状态事件。 它更适合分析 Running、Ready 和 Wait。
Running: thread owns a CPU
Ready: thread can run but is waiting for CPU
Wait: thread cannot run until an event occursReady 时间高可能说明：
- CPU 饱和；
- 高优先级线程干扰；
- 线程亲和性限制；
- 容器或 Job 配额；
- 过多 Runnable 线程。
Wait 时间高则继续检查等待原因和唤醒线程。
关键路径
一次操作的关键路径由必须按因果顺序完成的线程活动组成。
UI thread waits
-> worker thread waits
-> file I/O completes
-> worker readies UI thread在 CPU Usage (Precise) 中查看：
- New Thread ID；
- Ready Thread ID；
- Readying Process/Thread；
- Wait Reason；
- New Thread Stack；
- Ready Thread Stack；
- Switch-In Time；
- Ready Time。
沿“谁唤醒了当前线程”向前追踪，直到解释完整延迟。
Disk Usage 与 File I/O
磁盘图可以回答：
- 哪个进程发起 I/O；
- 读写大小；
- 文件路径；
- 队列与服务时间；
- I/O 调用栈；
- 访问是否集中或随机。
File I/O 事件描述 API 和文件层活动。 Disk Usage 更接近设备层。
页缓存命中时，文件读取可能没有对应物理磁盘 I/O。 必须结合两层判断。
Memory 与 Heap
根据采集 Profile，WPA 可以观察：
- Working Set；
- Commit；
- Page Fault；
- Virtual Allocation；
- Heap Allocation；
- 内存随时间变化；
- 分配调用栈。
Heap Trace 数据量和开销可能很大。 应限定进程和时间窗口。
DPC/ISR
DPC/ISR 图用于观察驱动和中断相关 CPU 活动。
音视频卡顿、输入延迟和设备问题可能与长 DPC/ISR 有关。
需要按模块和 Stack 查看，不能只看总百分比。
启动与关机
WPR 支持 Boot、Shutdown、Standby 等 On/Off Scenario。 这些采集涉及专用启动记录流程，命令应以当前官方文档和 wpr -help boottrace 为准。
WPA 可分析：
- Process Lifetime；
- Image Load；
- 服务启动；
- 磁盘与 CPU；
- 登录和 Shell；
- 关键启动活动。
WPA 分析模板
WPA Profile 可以保存图、列、聚合和布局。 团队应为常见场景保存共享 .wpaProfile：
- UI Responsiveness；
- CPU Hotspot；
- Thread Wait；
- Disk I/O；
- Startup；
- Background Power。
模板减少每个人重复拖拽，但不替代对事件含义的理解。
第4节：Intel VTune Profiler——CPU、线程与微架构分析
VTune 面向应用与系统性能分析，可在 Windows 和 Linux 上分析 CPU、多线程、内存、I/O 和部分 GPU/NPU 场景。
使用逻辑不是一次运行所有分析。
Hotspots
-> algorithm or hot call path?
-> Threading / HPC Characterization
-> Memory Access / Microarchitecture Exploration
-> GPU Offload or GPU Hotspots when relevantHotspots
Hotspots 是常见第一步。 它回答：
- 哪些函数占 CPU 时间；
- 哪些调用路径最热；
- Self 与 Total 时间；
- 哪个进程或线程执行；
- 热点源码行；
- CPU 利用率随时间如何变化。
命令行基本形式：
vtune -collect hotspots -- ./my_application --input model.datWindows 目标同样使用 -- 分隔 VTune 参数与应用参数：
vtune -collect hotspots -- C:\apps\my_application.exe --input model.dat具体 Knob 通过当前安装版本查询：
vtune -help collect hotspotsUser-Mode 与 Hardware Sampling
User-Mode Sampling 不需要硬件采样驱动，聚焦目标应用并采集调用栈。
Hardware Event-Based Sampling 使用 PMU 事件，可以获得系统级 CPU 时间和微架构指标，但需要相应权限、驱动或 Linux Perf 支持。
先根据环境能力选择采样模式。 虚拟机和容器可能限制硬件事件。
Bottom-up、Top-down 与 Caller/Callee
Bottom-up 从热函数向调用者聚合。 适合找“哪个函数贵”。
Top-down Tree 保留调用树。 适合找“从哪个业务路径进入热点”。
Caller/Callee 查看选中函数的直接父子关系。 适合判断热点是自身成本还是昂贵子调用。
Threading
Threading 分析回答：
- 核心利用是否均衡；
- 并行区域有多少并行度；
- 线程在哪些同步对象等待；
- 串行区在哪里；
- 负载是否均衡；
- 线程数变化是否有效；
- OpenMP/oneTBB 调度是否产生开销。
vtune -collect threading -- ./my_parallel_app看到低 CPU 利用时，不要立即增加线程。 先区分串行工作、锁等待、任务不足和 I/O。
HPC Performance Characterization
HPC Characterization 用于计算密集应用的整体分类。
它通常帮助观察：
- CPU Utilization；
- Memory Bound；
- Vectorization；
- FLOP 与数据类型；
- OpenMP/MPI 特征；
- 负载均衡。
它适合从节点级全景选择下一项深度分析。
Microarchitecture Exploration
微架构分析使用硬件事件解释流水线槽位。
常见方向：
- Retiring；
- Frontend Bound；
- Bad Speculation；
- Backend Bound；
- Core Bound；
- Memory Bound。
分类用于缩小方向。 它不能直接替代源码、调用栈和验证实验。
Memory Access
Memory Access 分析用于定位：
- Cache Miss；
- DRAM 带宽；
- 内存延迟；
- NUMA 远端访问；
- 数据对象与热点访问；
- 带宽饱和；
- 内存绑定源码。
vtune -collect memory-access -- ./my_application分析结果应与工作集、数据布局和线程放置结合。
Memory Consumption
Memory Consumption 关注分配、释放、对象存活和增长。
它回答“内存在哪里分配、由哪个调用路径保留”，不等同于 Memory Access 的 Cache/NUMA 分析。
I/O 分析
VTune 可以帮助区分应用 CPU 时间与 I/O 等待，并定位 I/O 调用路径。
对于 Windows 系统级 I/O 因果，WPR/WPA 往往提供更完整的 ETW 时间线。 对于应用源码热点和 Intel CPU 微架构，VTune 更直接。
GPU 与 Offload
VTune 的 GPU 相关分析用于 Intel GPU、SYCL、OpenCL、OpenMP Offload 等场景。
它可以观察：
- CPU/GPU Bound；
- Offload 时间线；
- 数据传输；
- GPU Kernel；
- GPU 硬件指标；
- 指令与内存瓶颈。
NVIDIA CUDA 的系统与 Kernel 深度分析通常分别使用 Nsight Systems 和 Nsight Compute。
结果对比
VTune 可以对比优化前后结果，但前提仍是工作负载和环境一致。
比较：
- Elapsed Time；
- CPU Time；
- Hot Function；
- Thread Wait；
- Memory Bound；
- Bandwidth；
- Vectorization；
- GPU Offload；
- 正确性和资源峰值。
VTune 常见误用
- 一开始运行最重的全部指标；
- 没有调试符号；
- 用 Debug 构建；
- 采集窗口包含无关初始化；
- 把低利用率直接等同线程不足；
- 看到 Memory Bound 就盲目预取；
- 忽略算法和数据规模；
- 优化后只对比百分比；
- 不重新采集同一分析。
第5节：Nsight Systems——系统级 Timeline
基本用法
# 抓取性能数据
nsys profile --trace=cuda,nvtx,osrt \
--output=my_profile \
./my_cuda_app
# 生成 .qdrep 文件
# 用 Nsight Systems GUI 打开查看
# 或者命令行快速查看
nsys stats my_profile.qdrep输出解读
┌─────────────────────────────────────────────────────────────┐
│ nsys timeline 输出示例 │
├─────────────────────────────────────────────────────────────┤
│ │
│ GPU Core： │
│ ┌────────┬────────┬────────┬────────┬────────┐ │
│ │Kernel A│Kernel B│Kernel A│Kernel C│ Idle │ │
│ └────────┴────────┴────────┴────────┴────────┘ │
│ 0ms 5ms 10ms 15ms 20ms 25ms │
│ │
│ 观察：Kernel A 和 B 顺序执行，没有并行！ │
│ → 可以用 CUDA Stream 并行化 │
│ │
│ GPU Utilization: 45% │
│ CPU-GPU Memcpy: 30% │
│ GPU Kernel: 45% │
│ Idle: 25% │
│ │
└─────────────────────────────────────────────────────────────┘常见问题的 timeline 特征
┌─────────────────────────────────────────────────────────────┐
│ 典型问题识别 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 问题1：CPU-GPU 传输瓶颈 │
│ Timeline: [H2D][GPU][D2H][H2D][GPU][D2H] │
│ 解决：用 CUDA Stream 重叠传输和计算 │
│ │
│ 问题2：GPU 空闲等待 │
│ Timeline: [GPU-Kernel][CPU-Preprocess][GPU-Kernel] │
│ 解决：Double Buffering，CPU 和 GPU 并行 │
│ │
│ 问题3：kernel 顺序执行 │
│ Timeline: [Kernel A][ Kernel B ] │
│ 解决：用多个 CUDA Stream 并行 │
│ │
│ 问题4：频繁的小 kernel 调用 │
│ Timeline: [K1][K2][K3][K4][K5][K6][K7][K8] │
│ 解决：合并多个小 kernel 为一个 │
│ │
└─────────────────────────────────────────────────────────────┘第6节：Nsight Compute——Kernel 级分析
基本用法
# 抓取 kernel 级别数据
ncu --set full \
--output my_kernel_profile \
./my_cuda_app
# 或者针对特定 kernel
ncu --set full \
--kernel-name "matrix_mul_kernel" \
--output my_kernel_profile \
./my_cuda_app输出指标解读
┌─────────────────────────────────────────────────────────────┐
│ ncu 输出指标解读 │
├─────────────────────────────────────────────────────────────┤
│ │
│ SM Utilization： │
│ 值：75% │
│ 含义：75% 的时间 SM 在执行有效指令 │
│ 低原因：分支分化、Warp 等待内存、Occupancy 低 │
│ │
│ Memory [GB/s]： │
│ Achieved：1800 GB/s │
│ 说明：实际内存带宽使用 │
│ 对比 HBM2e 理论：2000 GB/s → 利用率 90% │
│ │
│ SM Active Cycles： │
│ 值：high │
│ 含义：计算单元利用率高 │
│ │
│ L1/TEX Cache Hit Rate： │
│ 值：60% │
│ 含义：40% 的内存访问走了全局内存（慢） │
│ 解决：增加共享内存使用 │
│ │
│ Warp Occupancy： │
│ 值：48 warps/SM │
│ 含义：每 SM 平均 48 个 warp 在调度 │
│ 对比最大 64 warps/SM → Occupancy 75% │
│ │
└─────────────────────────────────────────────────────────────┘瓶颈定位流程
┌─────────────────────────────────────────────────────────────┐
│ ncu 瓶颈定位流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Step 1: 查看 SM 活跃度与 Kernel 持续时间 │
│ ├─ 活跃度低：检查启动间隙、并行度与等待 │
│ └─ 活跃度高：继续区分计算、内存和延迟 │
│ │
│ Step 2: 查看 Warp Execution Efficiency │
│ ├─ 活跃线程比例低：结合源码检查分支发散 │
│ └─ 比例正常：检查 Stall、Occupancy 与指令依赖 │
│ │
│ Step 3: 查看 MemorySOL / ComputeSOL │
│ ├─ Memory SOL 高且内存 Stall 高：调查带宽/访问模式 │
│ ├─ Compute SOL 高：调查指令吞吐与算法 │
│ └─ 两者都低：调查延迟、依赖、负载不均和启动间隙 │
│ │
└─────────────────────────────────────────────────────────────┘第7节：PyTorch Profiler——训练性能分析
基本用法
import torch
from torch.profiler import profile, ProfilerActivity
with profile(
activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
record_shapes=True,
profile_memory=True,
with_stack=True
) as prof:
# 训练循环
for batch in dataloader:
output = model(batch.input)
loss = criterion(output, batch.target)
loss.backward()
optimizer.step()
# 打印耗时最多的 10 个操作
print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=10))输出解读
┌─────────────────────────────────────────────────────────────┐
│ PyTorch Profiler 输出示例 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Name CUDA Time % │
│ ──────────────────────────────────────────────────────────│
│ cudaLaunchKernel 1000 ms 10%│
│ amp::fastMixedPrecisionKernel 2500 ms 25%│
│ layernorm_forward 1200 ms 12%│
│ embedding_forward 800 ms 8% │
│ tensor_expr_gpu_kernel 600 ms 6% │
│ aten::matmul 400 ms 4% │
│ ... │
│ │
│ 观察：amp::fastMixedPrecisionKernel 耗时最长（25%） │
│ → 可能是 Tensor Core 利用率低 │
│ │
└─────────────────────────────────────────────────────────────┘导出和可视化
# 导出 Chrome Trace 格式
prof.export_chrome_trace("trace.json")
# 在 Chrome 浏览器打开：chrome://tracing
# 可以看到每个操作的时间线和调用栈
# 导出内存快照
prof.export_memory_timeline("memory.html", device_index=0)
# 查看显存使用随时间的变化第8节：实用调试流程
┌─────────────────────────────────────────────────────────────┐
│ 性能调试完整流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 系统级：nsys timeline │
│ ├─ CPU-GPU 传输是否重叠？ │
│ ├─ GPU 是否空闲等待？ │
│ └─ kernel 是否并行执行？ │
│ │
│ 2. Kernel 级：ncu profile │
│ ├─ SM Utilization 高还是低？ │
│ ├─ 内存带宽利用率？ │
│ └─ Warp 效率？ │
│ │
│ 3. 热点分析： │
│ ├─ 哪个 kernel 占时间最多？ │
│ ├─ 哪个操作显存占用最大？ │
│ └─ 哪层耗时最长？ │
│ │
│ 4. 针对性优化： │
│ ├─ 内存带宽瓶颈 → 合并访问、共享内存复用 │
│ ├─ Warp 效率低 → 减少分支分化 │
│ ├─ CPU-GPU 不同步 → Double Buffering │
│ └─ Occupancy 低 → 调整 block 大小 │
│ │
└─────────────────────────────────────────────────────────────┘"AI 可查 vs 必须理解"清单
AI 可查：
✅ nsys/ncu 的具体命令行参数
✅ PyTorch Profiler 的具体配置选项
✅ Chrome Trace 格式的解读方法
必须理解：
🔴 nsys = 系统级 timeline，定位 CPU-GPU 协同问题
🔴 ncu = kernel 级分析，定位单 kernel 性能瓶颈
🔴 SM 活跃度低只是线索，需要结合启动间隙、并行度和 Stall
🔴 Memory SOL 高表示更接近内存路径上限，是否为瓶颈还需结合 Stall 与字节流量
🔴 PyTorch Profiler = 训练性能分析，定位哪层最慢第9节：工具选择矩阵
| 现象 | 第一工具 | 提供的信息 | 下一步 |
|---|---|---|---|
| Windows 应用偶发卡顿 | WPR + WPA | 全系统 ETW 时间线、线程、I/O | 沿关键路径下钻 Stack |
| Windows CPU 热点 | WPA Sampled 或 VTune Hotspots | 进程、线程、函数、调用栈 | 源码与微架构分析 |
| Windows 线程长等待 | WPA Precise | Running/Ready/Wait、唤醒链 | 找持锁方、I/O 或干扰线程 |
| Intel CPU 算法热点 | VTune Hotspots | Self/Total、调用树、源码行 | Threading 或 Microarchitecture |
| 多线程扩展差 | VTune Threading | 并行度、同步、负载不均 | 调整任务和共享状态 |
| Cache/NUMA/带宽 | VTune Memory Access | Memory Bound、带宽、NUMA | 数据布局与线程放置实验 |
| NVIDIA GPU 时间线 | Nsight Systems | CPU/GPU、Memcpy、Kernel、同步 | 选择目标 Kernel |
| NVIDIA 单 Kernel | Nsight Compute | Warp、SM、内存、指令指标 | 修改 Kernel 并复测 |
| PyTorch 层与算子 | PyTorch Profiler | Operator、CPU/CUDA 时间、内存 | 对热点进入 nsys/ncu |
工具选择遵循“先宽后深”。 先定位耗时阶段，再采集更重的微架构指标。
第10节：跨工具工作流
Windows 桌面卡顿
WPR record UI + CPU + Disk
-> WPA locate frozen interval
-> CPU Precise follow wait/readiness chain
-> CPU Sampled inspect On-CPU stacks
-> VTune profile isolated compute hotspot if needed
-> fix and repeat identical WPR scenarioCPU 求解器变慢
Benchmark confirms regression
-> VTune Hotspots locates call path
-> Threading checks imbalance and waits
-> Memory Access / Microarchitecture checks mechanism
-> modify one factor
-> benchmark + same VTune analysisGPU 任务利用率低
Nsight Systems
-> distinguish CPU preparation, copy, launch and idle
-> select dominant or problematic kernel
Nsight Compute
-> inspect warp stalls, memory and compute paths
-> modify
-> return to Nsight Systems for end-to-end validation第11节：采集前检查
- 使用 Release 或目标部署构建；
- 保留匹配符号；
- 固定输入和配置；
- 记录提交、机器和驱动；
- 缩短到问题窗口；
- 关闭无关日志；
- 确认磁盘空间；
- 明确管理员/驱动权限；
- 先测无 Profiler 基线；
- 记录正确性结果。
第12节：采集扰动
Profiler 会改变程序。
扰动来源：
- 采样中断；
- Stack 展开；
- ETW Provider；
- 文件写入；
- 硬件计数器复用；
- GPU Replay；
- 记录 Shape/Memory；
- 符号化；
- Debug Marker。
先使用低开销采集。 重分析仅在短而可重复的目标区域运行。
第13节：符号与源码映射
没有符号时，工具只能显示地址或模块。
需要保存：
- Windows PDB；
- Linux DWARF 或独立 Debug File；
- Build ID；
- 动态库版本；
- JIT Symbol；
- 源码提交；
- 编译路径映射。
错误符号比没有符号更危险，会给出错误函数名。
第14节：结果存档
每次调查保存：
- 原始 ETL、VTune Result、nsys/ncu 报告；
- 工具版本；
- 采集命令；
- Profile 配置；
- 输入数据；
- 构建哈希；
- 环境；
- 关键截图或导出表；
- 根因假设；
- 修改与复测结果。
大报告可以放制品存储，仓库只保存索引和结论。
第15节：官方资料
- Windows Performance Toolkit
- WPR 简介
- WPR 内置采集 Profile
- WPA 图表列表
- WPA CPU 分析
- Intel VTune Profiler
- Intel VTune 文档入口
命令参数和分析名称以本机安装版本的 -help 与最新官方文档为准。
学习状态：🟡 开始学习