lazygophers/perf-optimization

性能优化 · 跨栈方法论框架

"You can't tell where a program is going to spend its time. ... don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." —— Rob Pike, Rule 1

顶层是跨栈共识方法论,下设系统/前端/低延迟三个子流派框架,辅以流派间的真实分歧。分析任一性能问题,产出三件事:① 当前该做哪一步(度量/定位/优化/验证)② 用哪个流派的镜片 ③ 要避开哪个陷阱。

核心戒律:不靠猜,先量测。

待分析的性能问题

$ARGUMENTS

若上方为空,说明未带入参——直接按用户当前对话中的性能问题处理。

第一动作(任何性能问题先做)

先执行这一步,再决定怎么答:

1. 判型:是「具体系统/代码/页面慢」还是「抽象方法论问」?
   • 抽象 → 直接走核心方法论 + 张力(跳到对应章节),不必要数据。
   • 具体 → 进第 2 步,先要数据,后给方案。
2. 要数据(具体问题必做,缺一不可往下走):
   • 「当前的具体数字是多少?」——不接受「很慢/4 秒」这类模糊值,追问:是哪个指标(LCP 还是 onload?p75/p99 还是单次)?
   • 「有没有 profiling / 火焰图 / 瀑布图 / 执行计划?还是凭感觉?」
   • 「baseline 和可复现的负载条件是什么?」
3. 🛑 STOP — 停下来的信号:若上述数据一项都拿不到,不要凭猜开优化药方。明确告诉用户: 「在拿到 ___ 数据前,我只能给方向不能给结论。要么你补 ___,要么我先教你怎么测。」(具体怎么"不空手"见 Step 3 降级路径)

---

回答工作流

性能判断必须基于证据,不基于直觉。遇到需要事实的问题,先获取数据再回答。

Step 1: 问题分类

| 类型 | 特征 | 行动 | |------|------|------| | 需要现状数据 | 涉及具体代码/系统/页面的「为什么慢、怎么优化」 | → 先逼出度量数据 + 必要时查最新最佳实践(Step 2) | | 纯方法论问题 | 「性能优化的一般思路」「该不该过早优化」等抽象问 | → 直接用核心方法论回答(跳到 Step 3) | | 混合问题 | 用具体场景讨论一般原则 | → 先确认场景事实,再用框架分析 |

判断原则:如果回答质量会因缺少真实测量数据或该领域最新阈值/工具而显著下降,必须先获取,不靠训练语料臆测。

Step 2: 框架式研究(按问题类型选择)

⚠️ 涉及"现在多慢/瓶颈在哪"时,必须先向用户要数据或用工具查证,不可凭训练语料臆测。

研究维度(从核心方法论反推,按需取用):

维度 A — 度量现状(对应方法论「测量先于优化」)

• 有没有 baseline?当前延迟/吞吐/资源占用的具体数字是多少?
• 测量环境与负载是否可复现?用的是均值还是 p95/p99 分布?
• 有没有 profiling 数据(火焰图、trace)?还是凭感觉认为"这里慢"?

维度 B — 瓶颈定位(对应方法论「瓶颈思维/Amdahl」)

• 哪个资源/层主导了成本?(一个热锁?一个慢依赖?一块过载磁盘?一种 GC 暂停?)
• 问关键问题:"什么能解释我们看到的大部分延迟?"
• 待优化部分占总时间的比例 p 是多少?(Amdahl 上限 = 1/(1-p),占比小则优化无意义)

维度 C — 领域最佳实践与阈值(对应具体流派,需联网查最新值)

• 前端问题 → 查 web.dev 最新 Core Web Vitals 阈值(LCP≤2.5s / INP≤200ms / CLS≤0.1,注意 INP 已于 2024 取代 FID)、关键渲染路径、性能预算。
• 系统/后端问题 → USE 方法逐资源体检(CPU/内存/磁盘/网络的 利用率/饱和度/错误)、Off-CPU 分析、火焰图。
• 低延迟/高并发问题 → cache line/false sharing、单写者、GC 分配率、尾延迟与协调遗漏。

维度 D — 硬件/运行时约束(对应方法论「机制同理心」)

• 数据访问模式是否缓存友好?(顺序 vs 随机、AoS vs SoA)
• 有没有跨线程写竞争?GC/分配率?JIT 预热是否影响测量?

研究输出格式

内部整理事实摘要(不输出给用户),然后进入 Step 3。用户看到的不是一堆数据罗列,而是基于真实数据的方法论判断。

🔴 CHECKPOINT — Step 2.5: 回答前自检关卡(走完才能进 Step 3)

输出前逐条核对,任一不满足就回到对应步骤,不要强行作答:

• [ ] 数据关:具体问题是否已拿到真实数字 / profiling?没有 → 回 Step 2 要数据,或显式降级(见 Step 3),禁止把猜测伪装成结论。
• [ ] 镜片关:是否选对流派镜片?(后端→USE/火焰图;前端→关键渲染路径/CWV;低延迟→机制同理心/尾延迟)
• [ ] 陷阱关:本场景该避哪个反模式?(尤其:只看均值不看尾部、断章取义 Knuth、微基准当结论)
• [ ] 越界关:是否落在「诚实边界」未覆盖区(数据库/GPU/网络协议/编译器)?是 → 给方法论层 + 明说专项未覆盖,不硬编专项细节。

🛑 另两个主动 STOP 信号:① 待优化部分占比 p 明显很小(Amdahl 收益被锁死)→ 先质疑「这值得优化吗」再给方案;② 问题落未覆盖专项且用户要专项细节 → 停在边界,建议另查专项资料。

Step 3: 框架式回答

基于 Step 2 的事实,运用核心方法论 + 对应流派镜片输出。回答应包含:当前该做哪一步、用哪个流派视角、要避开哪个陷阱。诚实标注不确定性(没有数据时明说"需要先测 X 才能判断")。

降级路径(用户无法/不愿提供数据时):不要卡死。改为交付"诊断剧本"——告诉用户该测哪几个指标、用什么工具(火焰图/USE 体检/CWV 实测/HDR Histogram)、拿到数据后怎么读、最可能的 2-3 个嫌疑方向及各自的验证实验。把"我猜瓶颈是 X"替换成"按此剧本测完,你就能自己定位",既守住"不靠猜",又不空手而归。

---

跨栈核心方法论(速查 · 所有流派共识)

每条都在 ≥2 个独立流派中复现。详解(证据/应用/局限)见 references/methodology.md。

| # | 方法论 | 一句话 | 关键依据 | |---|--------|--------|----------| | 1 | 测量先于优化 | 证明瓶颈位置前不动手 | Pike 规则 1-2、Gregg《Stop the Guessing》 | | 2 | 瓶颈思维 | 先猎杀主导成本,5 处各砍 5% 没用 | Amdahl 定律 1/((1-p)+p/s) | | 3 | 看尾部不看均值 | p99/p999 才是真实上限 | Gil Tene、SRE 四黄金信号 | | 4 | 只优化关键 3% | 不瞎操心,但绝不放过关键 3%(先识别再优化) | Knuth 1974 | | 5 | 机制同理心 | 数据访问模式 > 算法巧思,为硬件写软件 | Thompson、Acton、Pike 规则 5 | | 6 | 科学方法循环 | 假设 If X then Y → 测 → 验证 → 迭代 | Gregg、Bentley | | 7 | trade-off 耦合 | 延迟与吞吐由 Little 定律耦合,控制而非消除 | Little 定律 L=λW |

---

流派对比(子框架 · 按问题领域选镜片)

| 维度 | 系统/后端(Gregg) | 前端/Web(Souders/Osmani) | 低延迟/高并发(Thompson/Acton) | |------|------------------|--------------------------|-------------------------------| | 核心镜片 | 资源瓶颈定位 | 用户感知的加载/交互体验 | 贴硬件消除竞争与抽象开销 | | 看什么 | CPU/内存/磁盘/网络的 U/S/E | 关键渲染路径、Core Web Vitals | cache line、写竞争、GC、尾延迟 | | 招牌方法 | USE 方法、火焰图、Off-CPU、eBPF | RAIL、性能预算、PRPL、CWV | Disruptor、单写者、零分配、机制同理心 | | 关键指标 | 延迟、饱和度、错误 | LCP≤2.5s / INP≤200ms / CLS≤0.1 | p99/p999、纳秒级延迟、分配率 | | 何时用 | 服务器/后端"哪个资源是瓶颈" | 网页"加载慢/交互卡/布局跳" | 交易/游戏/实时系统"延迟不可预测" |

症状 → 镜片快速映射(问题模糊时先用此表定位起点)

用户先报"症状"、未必自判领域。先用此表选起点镜片,具体判断仍须 Step 2 逼出真实数据。

| 用户症状 | 先用哪个镜片 | 第一个该问的问题 | |----------|--------------|------------------| | 卡顿/掉帧/界面不流畅 | 前端(INP/CLS)或低延迟(主线程阻塞) | 网页交互卡还是动画掉帧?有没有长任务? | | OOM/内存溢出/内存泄漏 | 系统(USE 内存饱和度) | 稳态高占用还是持续增长?有堆 dump 吗? | | GC 频繁/GC 停顿 | 低延迟(分配率) | 分配率多少?停顿是否落在 p99 尾部? | | 慢查询/SQL 慢/接口超时 | 系统(逐资源 USE)+ 尾部分布 | 均值慢还是 p99 慢?瓶颈在 DB/网络/应用哪层? | | 打包体积大/bundle 太大 | 前端(关键渲染路径 + 性能预算) | 当前 bundle 多大?有没有预算入 CI? |

三个镜片的展开(USE 三指标、关键渲染路径与 CWV 阈值、机制同理心/单写者/Disruptor)+ 各镜片工具箱,见 references/schools.md。

---

决策启发式

1. 优化前先建 baseline:量化"现在多慢"+ 定义可复现负载。没有 baseline 就无法证明收益或发现回归。
2. 先 USE 体检再深钻:系统问题先逐资源查 U/S/E 做广度筛查,定位后再深入,而非一头扎进熟悉的工具。
3. 假设写成 "If X then Y" 再测:把直觉变成可证伪的实验,而不是改一堆东西看哪个碰巧管用。
4. 先问"什么解释大部分延迟":锁定主导成本,拒绝在占比 5% 的地方较劲(Amdahl)。
5. 微基准必须复现生产条件 + 防优化器作弊:核心铁律——被测结果和输入都必须被"消费",否则编译器/JIT 合法删掉它。要预热到稳态、做统计而非单点。各语言防优化 API:Java Blackhole.consume(JMH)、Go for b.Loop()(1.24+,自动防 DCE)或包级 sink 变量、Rust std::hint::black_box(criterion 已内置)、C++ benchmark::DoNotOptimize() + ClobberMemory()。否则数字"看着可信但根本误导"。
6. 报分位数不报均值,压测用开环:p95/p99/p999 才反映真实;闭环压测有协调遗漏,改用恒定速率开环生成(wrk2/k6)。
7. 跨线程可变字段做 padding,业务逻辑单写者:消除伪共享与写竞争;无锁只用于底层组件。
8. 前端先压关键渲染路径 + 设性能预算入 CI:优先首屏关键资源;用预算防功能堆积导致的退化。
9. 性能左移有度:关键路径在架构期就贴硬件设计(事后 profiling 救不回);非关键路径别提前抽象、也别为显摆"不优化"而过早劣化。

---

反模式速查(明确反对的做法)

• Gregg 反方法论:路灯反方法(只用熟悉工具)、随机改动(凭运气调参)、甩锅(无证据归咎他人)、照搬清单(不懂为什么)。
• 断章取义 Knuth:只引"过早优化是万恶之源",丢掉"关键 3% / 先识别再优化"。
• 过早劣化:以"避免过早优化"为名随手写低效代码(该传引用却传值)。
• 微基准当结论 / 数字不追因:把被 DCE/常量折叠/未热身污染的数字当真,或不问"为什么是这个数"。
• 只看均值忽略尾部、臆想硬件(基于过时硬件模型)、过度抽象(为不会出现的需求上泛化)。

---

内在张力(速查 · 判断力来源)

性能优化无统一教条,分歧本身是判断力来源。详解(双方原话/出处/真实性标注)见 references/tensions.md。

| # | 分歧 | 一句话 | |---|------|--------| | 1 | Knuth 被滥用 vs 原意 | 原文捍卫合理效率,只反对非关键路径瞎操心 | | 2 | 过早优化 vs 过早劣化 | 双侧约束:既不臆想优化,也不为"不优化"而劣化 | | 3 | 可维护性 vs 数据导向(OOP vs DOD) | 省程序员周期 vs 省机器周期;非关键系统前者赢 | | 4 | 自上而下找瓶颈 vs 自下而上贴硬件 | 先测量定位 vs 架构期贴硬件;实践常互补 | | 5 | 微基准 vs 真实负载 | 隔离测量被自适应优化扭曲,须复现生产条件 |

---

失败处理(触发 → 一线 → 兜底)

| 触发 | 一线修复 | 仍失败兜底 | | --- | --- | --- | | 用户给不出任何测量数据 | 转交付"诊断剧本"(该测什么/用什么工具/怎么读)| 先帮搭测量(APM/profiler/clinic),标注"未测,仅方向性建议" | | 优化后无改善或更差 | 回 baseline 重测,确认只改了一个变量;质疑是否真瓶颈(Amdahl p 是否够大)| 换镜片重新定位;承认当前假设错,回 Step 2 重新逼数据 | | 微基准数字好得离谱 | 怀疑 DCE/常量折叠/未热身,按防优化 API 重测(见 references/benchmarking.md)| 改用真实负载/宏基准,标注微基准不可信 | | 压测 p99 与线上不符 | 查是否闭环压测(协调遗漏),改开环 wrk2/k6 恒定速率 | 用线上 RUM/真实流量回放校准 | | 问题落未覆盖专项(DB/网络/GPU/编译器)| 给方法论层定位到该专项边界为止 | 明说专项未覆盖,建议另查专项资料,不硬编专项细节 |

适用边界

• 不替代实际测量:框架给"怎么想",真实瓶颈只有 profiling 数据能回答。
• 阈值会过时:Core Web Vitals 阈值、INP 取代 FID 等指标持续演进,涉及具体数字应联网核对最新值。
• 未覆盖专项:数据库查询优化、网络协议调优、编译器优化标志、GPU/异构计算等专门领域未单独成章——落到这些专项时给方法论层并明说,不硬编专项细节。

参考集(按需读)

references/methodology.md(7 跨栈方法论详解, 证据/应用/局限) · schools.md(三流派镜片展开 USE/关键渲染路径+CWV/机制同理心 + 工具箱) · tensions.md(5 对内在张力详解, 双方原话/出处/真实性标注) · benchmarking.md(微基准防优化器作弊 4 语言 API + 压测防协调遗漏)