性能优化不靠剖析热点，靠理论峰值反推差距
软件慢 10 到 100 倍的根因不在代码技巧，而在架构层的串行依赖；正确优化是锁定硬件理论峰值再量差距——前提是架构决策者懂汇编。
核心论点 · 点时间戳可跳到原声
性能被忽视的三个原因
Casey 认为开发者普遍不关注性能，机制有三层：企业软件里用户不是购买者，决策者只看成本、合规与法律责任，性能好坏不影响成交；垄断效应让社交网络这类平台难以靠性能被挑战，体验再差用户也走不了；第三个原因是过去十年呼吁性能的人已经产生效果，性能正在重新被重视。三条叠加解释了为什么「让软件变快」在公司里常常没有话语权，也说明性能问题本质是激励问题。
— Casey Muratori理论峰值是优化正确起点
Casey 强调行业里真正的优化专家不会先剖析再改热点。正确顺序是：先问这个系统必须执行哪些操作，再查底层硬件在理论峰值下能做什么，然后测量理论最大值与当前实现之间的差距，最后努力缩小差距。这样做有两个好处：不会被局部热点带偏，能发现硬件新特性，进而提升自己的优化能力。他明确指出「先测量热点再优化」不是专家做法，而是把优化当成事后补救。
— Casey Muratori串行依赖链才是万恶之源
「过早优化是万恶之源」这句话的真正问题在于：如果架构阶段就形成了串行依赖链，后期靠优化热点根本无法挽救。Casey 举例，代码模式若是「请求-处理-再请求」，性能专家也无能为力，因为串行依赖无法并行化。软件的性能通常由最长的串行依赖链决定，而这条链在架构期就定型了。所以架构选择一旦出错，后续所有性能优化都是在错误的地基上盖楼。
— Casey MuratoriAI 公司正重写技术栈
Uber 曾因 Python 和 Node.js 的单线程问题转向 Go 和 Java。如今 OpenAI 和 Anthropic 面临同样的故事：数据科学家熟悉 Python，所以初版全用 Python，但产品要支撑多线程和更多连接，现在开始评估迁移到 Rust 或 Go。Casey 的潜台词是，AI 公司正在经历基础设施的「语言债务」期，而这一幕在上一代互联网公司身上已经发生过，历史正在重演。
— Casey MuratoriGTA6 是替换 GTA5 的生意
Casey 从商业结构解释 GTA6 为什么开发周期那么长：GTA5 在线模式当时是收入最高的娱乐产品，年入数十亿美元。GTA6 不是做一个新游戏，而是替换公司最赚钱的产品，所以 Rockstar 和 Take Two 不能失败，还得规划在线部分，避免新产品蚕食旧产品收入。GTA5 的成功对他们是意外，GTA6 是第一次真正更新旗舰产品，相当于重新发布 Google 搜索——这是极端保守的开发逻辑。
— Casey Muratori真正成本是编译器被蒙在鼓里
很多人以为虚函数调用本身开销大，Casey 纠正说真正代价是编译器失去优化能力。当编译器无法确定运行时类型时，就无法内联、合并冗余代码、做向量化，性能损失远大于一次间接调用。他在 Clean Code 视频里展示的退化还相对温和，实际生产环境可能更严重。多态代码慢的不是那一次分派，而是整个周围代码都失去了被自动化的资格。
— Casey Muratori原话 · 已逐字校验
That is not how anyone has ever, you know, I've worked with many extremely good optimization people, and that is not how it is done. The correct way to do optimization is very much like what you just said. You first go, what are the operations that this system has to perform? What is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
这不是任何人曾经做过的方式，我合作过许多极其优秀的优化专家，这不是他们的做法。正确的优化方式正如你所说：首先，这个系统必须执行哪些操作？底层硬件在理论峰值时能做什么？然后你测量理论最大值与你实际达到之间的差距。
Casey Muratori22:29
The performance of your software is generally determined by the longest serial dependency chain because it's something that cannot be paralyzed.
软件的性能通常由最长的串行依赖链决定，因为这是无法并行化的。
Casey Muratori33:53
The way to think about it is your code base will not end up that way by accident. In most cases anymore. You have to engineer up front for a hotspot code base that people can then optimize.
思考方式是，你的代码库不会偶然变成那样。在大多数情况下，你必须预先设计一个可优化的热点代码库，以便人们后续优化。
Casey Muratori35:56
Grand Theft Auto 5 at the time was, if I'm not mistaken, by far the most revenue generating entertainment product in existence. The online part of that game was generating like billions of dollars.
如果我没记错的话，GTA5 当时是现存收入最高的娱乐产品。它的在线部分产生了数十亿美元的收入。
Casey Muratori1:13:25
in my experience, usually the code that is architected properly is also the code that runs quickly.
根据我的经验，架构良好的代码通常也运行得快。
Casey Muratori1:25:13
I don't think people should necessarily take a book recommendation from me. I want to recommend that people read a paper.
我不认为人们应该接受我的书单推荐。我想推荐人们去读论文。
Casey Muratori1:50:13
I don't know if they're good at that, but I'm guessing that's something they could do.
我不知道他们是否擅长这个，但我猜这是他们能做的事情。
Casey Muratori1:51:15
数字与实体
| 软件运行速度比需要慢的倍数 | 10x-100x | 0:00 |
| Linear 操作预算 | 300ms | 19:22 |
| 网络 ping 时间 | sub 10ms | 20:25 |
| Python 中 A+B 的汇编指令数 | 远多于 C 的一条 add 指令 | 44:26 |
| Steam 年发布游戏数 | 数万到十万 | 1:07:59 |
| Clean Code 视频性能差距 | 1.5 到 15 倍 | 1:16:32 |
| GTA5 在线收入 | 数十亿美元 | 1:13:25 |
| AI 代码质量转折点 | 2024 年 1 月 | 1:38:46 |
| AI 全面评估所需时间 | 至少 6 个月到 1 年 | 1:39:47 |
术语
- theoretical peak理论峰值
- 硬件在理想条件下能达到的最大吞吐，是优化目标的基准。
- serial dependency chain串行依赖链
- 一系列无法并行、必须顺序执行的操作，决定软件延迟下限。
- hotspot热点代码
- 程序中消耗最多 CPU 时间的部分，常是优化的自然切入点。
- branch prediction分支预测
- CPU 预测分支走向以保持流水线满载的机制，预测失败代价高。
收听指南
写后端或业务代码的程序员、做技术选型的架构师，以及正在用 AI 重写技术栈的初创团队——产品慢但说不清慢在哪的人尤其该听。
若时间紧可跳过 1:16 到 1:25 的 Clean Code 视频复盘，听结论即可；游戏行业部分看似离题，其实是全片最有预测力的内容。