CPU性能分析
概述 CPU性能分析可以识别消耗最多CPU时间的函数，从而有针对性地优化昂贵的代码路径。
何时使用
- 高CPU使用率
- 执行速度慢
- 性能回归
- 优化前
- 生产监控
指令
1. 性能分析工具
浏览器性能分析：
Chrome DevTools：
步骤：
1. DevTools → Performance
2. 点击记录
3. 执行操作
4. 停止记录
5. 分析火焰图
指标：
- 函数调用持续时间
- 调用频率
- 总时间与自身时间
Firefox Profiler：
- 内置性能分析器
- 火焰图
- 时间线视图
- 导出和共享
React Profiler：
- DevTools → Profiler
- 组件渲染时间
- 阶段：渲染与提交
- 为什么组件重新渲染
---
Node.js性能分析：
node --prof app.js
node --prof-process isolate-*.log > profile.txt
Clinic.js：
clinic doctor -- node app.js
clinic flame -- node app.js
显示：函数、内存、延迟
V8 Inspector：
node --inspect app.js
打开chrome://inspect
性能分析器标签
获取CPU性能分析
2. 分析与解释
// 理解性能分析
火焰图阅读：
- 越宽=花费时间越多
- 越高=调用堆栈越深
- 热点路径=宽高条
- 空闲=间隙
自身时间与总时间：
- 自身：函数本身的时间
- 总时间：自身+子函数
- 示例：
main()调用work()持续1秒
work()本身=0.5秒（自身）
work()本身+子函数=1秒（总时间）
热点识别：
- 查找最宽的条（最多时间）
- 检查是否可避免
- 检查是否可优化
- 更改前后进行性能分析
示例（V8分析）：
函数：dataProcessing
自身时间：500ms（50%）
总时间：1000ms
调用次数：1000次
每次调用时间：0.5ms
优化：减少调用频率
3. 优化过程
步骤：
1. 建立基线
- 性能分析当前行为
- 记录最热函数
- 记录总时间
- 检查系统资源
2. 识别瓶颈
- 查找前5个时间消耗者
- 分析调用频率
- 了解它们的功能
- 检查是否必要
3. 创建假设
- 为什么函数慢？
- 算法能否改进？
- 我们能否缓存结果？
- 我们能否并行化？
4. 实施更改
- 一次只更改一个
- 每次更改后测量影响
- 更改后性能分析
- 比较火焰图
5. 验证改进
- 基线：1秒
- 优化后：500毫秒
- 确认50%改进
---
常见优化：
算法改进：
之前：O(n²)嵌套循环=1000项100ms
之后：O(n log n)带排序+搜索=10ms
影响：快10倍
缓存：
之前：每次调用重新计算
之后：缓存结果，立即返回
影响：对于重复调用快1000倍
记忆化：
之前：fib(40)重新计算每个分支
之后：缓存计算值
影响：从指数到线性
延迟评估：
之前：预先计算所有值
之后：仅计算所需值
影响：部分结果减少90%以上
并行化：
之前：顺序处理，1000ms
之后：4核，250ms
影响：快4倍（8核=8倍）
4. 监控与最佳实践
监控：
生产性能分析：
- 轻量级采样性能分析器
- 典型开销1-5%
- 工具：New Relic, DataDog, Clinic
- CPU峰值警报
关键指标：
- 每个函数的CPU使用率%
- 调用频率
- 每次调用时间
- GC暂停时间
- P95/P99延迟
---
最佳实践：
优化前：
[ ] 性能分析以找到实际瓶颈
[ ] 不要猜测（用数据验证）
[ ] 建立基线
[ ] 测量改进
优化期间：
[ ] 一次只更改一件事
[ ] 每次更改后性能分析
[ ] 验证改进
[ ] 不要过早优化
过早优化：
- 先性能分析
- 仅热点路径（80/20规则）
- 测量影响
- 考虑可读性
---
工具总结：
框架：Chrome DevTools, Firefox, Node Profiler
分析：火焰图，调用树，时间线
监控：APM工具，Clinic.js
比较：前后性能分析
---
红旗：
- 意外的高CPU
- GC暂停>100ms
- 函数每次请求调用100万次
- 深层调用堆栈
- 循环中的同步I/O
- 重复计算
- 热循环中的内存分配
关键点
- 优化前先性能分析（测量，不猜测）
- 查找火焰图中宽高条
- 区分自身时间与总时间
- 首先优化顶级瓶颈
- 用测量验证改进
- 考虑缓存和记忆化
- 使用生产性能分析以解决实际问题
- 算法改进胜过微优化
- 测量前后
- 专注于热点路径（80/20规则)