performance-profilinglisted

# 性能调优 ## 何时用 - 系统出现明显变慢、延迟升高、资源使用异常时。 - 接到"优化这段代码"的任务,准备动手之前。 - 发现自己想"感觉这里可以缓存一下"但没有数据支撑时——这是需要先测量的信号。 - 在 code review 里看到未经测量的性能优化改动时。 ## 核心规则 ### 1. 先测量:用 profiler/benchmark 找真实瓶颈,不靠猜 **规则：** 任何优化动作之前,必须先用工具(profiler、benchmark、APM 追踪)找出真实的热点函数或慢路径,再决定优化什么。 **为什么：** AI 在"优化性能"任务中常先凭直觉下手:把字典查找换成数组遍历"因为听说数组快"、把 for 循环改成列表推导"因为更 Pythonic"。但实际瓶颈往往在完全不同的地方——90% 的时间花在一个数据库查询上,而 AI 在优化内存里的字符串拼接。没有数据的优化不仅收益不明,还可能引入新 bug 或降低可读性。 **怎么做：** - Python 用 `cProfile`/`py-spy`,Node.js 用 `--prof` 或 Chrome DevTools,Go 用 `pprof`。 - APM(Datadog、New Relic、Sentry)看生产慢请求的 trace,定位到具体函数调用。 - 先得到一份"热点函数列表"(火焰图或 top-N),再决定优化哪里。 --- ### 2. 优化热点,不过早优化冷路径;有数据支撑再改 **规则：** 只优化 profiler 确认的高频/高耗时路径,忽略执行频率低的冷路径;每次优化决策都要有性能数据作为依据。 **为什么：** AI 在生成代码时常做"预防性优化"——在一个每天调用 10 次的管理接口里用位运算替代普通算术,因为"更高效"。这些优化降低了代码可读性,却对实际用户体验毫无影响。真实的性能收益来自于优化那些每秒调用上千次或每次耗时数百毫秒的路径,而不是散落各处的"感觉更快"的改写。 **怎么做：** - 只处理 profiler 报告中占总耗时前 80% 的函数。 - 改之前记录基准数字(当前 P99 延迟、QPS 上限、内存峰值)。 - 对于冷路径,优先选择可读性好的实现,留注释说明"此处不是瓶颈,无需优化"。 --- ### 3. 关注算法复杂度与 I/O(N+1、同步阻塞、无缓存),常比微优化收益大 **规则：** 先检查 O(n²) 算法、N+1 查询、同步阻塞 I/O、无缓存的重复计算这类结构性问题,再考虑微观层面的优化。 **为什么：** AI 进行性能优化时容易去做微优化(内联函数、减少对象分配、换更快的序列化库),却忽视结构性问题。常见事故:一个列表页接口产生 N+1 查询——每条记录触发一次独立 DB 查询,100 条记录 = 101 次查询。把 JSON 序列化从 `json` 换成 `orjson` 节省了 1ms,但 N+1 查询吃掉了 500ms。结构性优化(改成一次 JOIN 查询)的收益是微优化的 100 倍。 **怎么做：** - 用数据库慢查询日志或 `EXPLAIN` 检查是否有 N+1、缺失索引、全表扫描。 - 检查热路径上是否有阻塞 I/O 可以改为异步或批量处理。 - 检查计算密集型结果是否有合适的缓存层(内存缓存/Redis),减少重复计算。 - 对循环内的数据库查询、HTTP 调用保持警惕。 --- ### 4. 改完再测量对比,确认真变快且没破坏正确性 **规则：**