跨国深谈← 返回←Casey Moratori：为什么你的软件慢了100倍

Casey Moratori：为什么你的软件慢了100倍

关联

人物 Casey Moratori

概念 性能优化 · 汇编语言 · 串行依赖链 · 过早优化 · 多态 · 游戏引擎

Casey Moratori 做了十几年游戏和底层性能工具，现在在 Substack 上做 Computer Enhance，教人写高性能代码。他说了一个很反直觉的事实：市面上大多数软件跑得比它应该的速度慢几十到上百倍 。

为什么没人关心性能

三个原因。第一，很多企业软件的购买者不是使用者——高层看合规和价格下单，根本不在意每个操作卡 30 秒 。

第二，垄断效应。社交网络这类平台有网络效应护城河，你做得再快也很难抢用户，性能只是加分项，不是决定因素 。

但第三点，趋势在变。Bunn 对比 NPM 快了 10 倍以上，Linear 把每个操作压到 300 毫秒以内，而 Jira 慢得多——这些产品用性能当武器切入市场，而且拿到了真实增长 。300 毫秒在计算里已经算「永恒」了，而现实中很多程序一个操作要等好几秒，网络延迟都比这快 。

正确的优化方法：先算理论上限

Casey 说大多数人对优化的理解就是错的。常见做法是：跑性能剖析，找到热点，改一改，看统计数字有没有变好。他说这不是优化，这只是「改进」——你找到的是一个局部最小值 。

真正的优化是：先算清楚底层硬件理论上能做到多快，再量你实际做到了多少，然后缩小这个差距 。你不需要挤到理论极限，但要能解释为什么没到。

这个方法还有一个好处：你能发现异常。Casey 在做 Substack 课程时就遇到过 Intel 芯片上有一种没人文档化的重命名机制，不看理论值你根本不知道它存在 。

为什么该学读汇编

Casey 反复强调：学汇编不是为了写汇编，而是为了读。你写的 Java、C、Rust 代码都只是编译器的输入，你根本不知道 CPU 实际收到了什么指令。看汇编输出，你才确切知道机器在干什么 。

而且汇编没你想的那么难。x64 里编译器实际输出的常用指令也就二三十条，比 React 加 CSS 加 DOM 的知识量小得多 。懂了汇编之后，CPU 厂商发布新芯片时的架构图你就能直接读懂——乘法吞吐量、缓存层级、分支预测，全写在图上 。

最直观的例子：Python 里做一次 A+B，底层可能要执行上百条 CPU 指令；C 语言里就是一条 add 指令 。理解了这个量级差异，你就知道为什么 Python 里必须调用 C 写的库来做重计算，也就能在写代码时判断：这个路径能不能承受 100 倍的减速 。

「过早优化是万恶之源」被滥用了

Casey 专门做了一场两小时的讲座拆这句话。他说这句话不是完全错，但大多数人拿它当借口，在应该考虑性能的时候不思考 。

真正的区分在于：你能不能确定现在写的代码，以后可以局部优化？如果能——比如换个更快的哈希表实现——那推迟没问题。问题出在架构层面：如果你整篇代码都是「问服务器→等响应→算一下→再问服务器→再等」的串行模式，最后发现慢了，性能专家来了也只能说「没办法，得重写」。

因为串行依赖链无法并行化，不是热点，是写法本身的问题。Facebook、Uber 都发过博客说「我们不得不把整个东西重写一遍」——如果只是热点问题，永远不会需要重写整个东西 。OpenAI 和 Anthropic 都经历了同样的路径：早期用 Python 因为数据科学家熟悉，后来发现单线程扛不住，开始转向 Rust 。

所以 Casey 的核心观点是：做架构决策的人必须懂性能，必须确保下游的人以后还有优化空间。否则就是在掷骰子 。

Clean Code 的性能代价

Casey 做过一期视频，展示 Uncle Bob Martin 推崇的多态重构模式比简单的表切换慢 1.5 到 15 倍。他说反响比预期好，没那么大争议 。

关键不是虚函数调用本身贵多少，而是你用了多态之后，编译器没法做内联、没法做代码折叠、没法做向量化——编译器被你挡在外面了 。如果你用的小函数都是静态已知的，编译器反而能把冗余代码全部折叠掉，跑得很快 。简单可读的代码和运行快的代码，在大多数情况下并不矛盾 。

游戏引擎的教训：降低门槛之后

Casey 把游戏引擎的普及比作「游戏行业的 AI 时刻」。以前每个游戏要自建渲染引擎，引擎风险是最大杀手——技术做不到，游戏就死了 。Unreal Engine、Unity 这些可授权引擎消除了这个风险，让更多人能做游戏 。

但结果是：Steam 上每年上架的游戏数以万计，你的游戏不可能被自然发现。游戏好变成了基本门槛，营销和分发才是真正的差异化因素 。再加上老游戏不会因为画面过时就被淘汰，以及 Fortnite、Minecraft 这些实时服务产品占据了玩家时间，新游戏的生存空间被进一步压缩 。

AI 与手工编程

Casey 在自己的项目里完全不用 AI 工具，原因很简单：他写游戏代码是因为他想写，不是为了产出 。他把这比作手工家具——IKEA 自动化了制造，但工业区里还是有人手工做桌子，这是人类会做的事，不需要商业理由 。

关于 AI 对行业的实际影响，他觉得现在评估太早。就算 AI 已经让生产力提升了 10%，这种幅度的提升从外部也很难观察到 。

但他注意到一个现象：工作中自主权高的人通常对 AI 体验积极——他们拿 AI 做自己不想做的事；而被强制要求使用 AI 的人更容易产生倦怠 。所以他的建议是，选工作时把自主权当成一个重要考量 。

本集带走

• 先算理论上限再优化：不要只跑性能剖析找热点，先算硬件理论上能做到多快，再量差距。这样你才能发现真正的异常，而不是停留在局部最小值。
• 学读汇编，不用学写：只需要二三十条常用指令，就能看懂 CPU 实际在做什么，进而读懂芯片架构图、判断语言层面的性能量级差异。
• 架构决策时要防串行依赖链：「先写再优化」的前提是你确定以后能局部优化。如果架构上制造了无法并行化的串行依赖链，后面只能重写。
• 别让编码教条挡住编译器优化：过度使用多态和虚函数会阻止编译器做内联和向量化，简单可读的代码在大多数情况下本身就很快。
• 选工作时把自主权当硬指标：自主权高的人能把 AI 当工具用在不想要的杂活上；被强制用 AI 的人更容易倦怠。

他还说，市面上大多数软件的运行速度比所需速度慢几十到几百倍。
He also says that most software out there runs tens to hundred times slower than it needs to.
—— 嘉宾 · [00:08]

所以关键点是，你团队中每一个正在做架构决策的人，那些人必须懂性能，而且他们必须做出能让那些在他们下游的其他人使用以后可以优化的架构的决策。
the crucial takeaway is everybody on your team who is making architectural decisions, those people must know performance and they must make decisions that will allow the other people downstream of them to use an architecture which can be optimized later.
—— Casey Moratori · [35:57]

如果总是热点让你的性能变差，你永远不需要重写整个东西。
If it was always hotspots that made your performance bad, you’d never have to rewrite the whole thing.
—— Casey Moratori · [39:23]

因为根据我的经验，通常架构正确的代码也是运行快速的代码。
Because in my experience, usually the code that is architected properly is also the code that runs quickly.
—— Casey Moratori · [85:08]