「硬件越来越快，软件越来越慢」——这句抱怨业界听了三十年，但总需要有人把它严肃地重新论证一遍。8 月 21 日，工程师、随笔作者 Dan Luu 在个人网站发表文章《There's no reason for software to be slow anymore》（原文链接），随即登上 Hacker News 首页（讨论区）。对熟悉他的人来说，这个标题没有任何修辞夸张的意图：他大概是业内少数把「软件为什么慢」当作正经学术问题来研究的人。
老议题，新弹药
Dan Luu 曾任职于微软、谷歌和 Twitter 的支付团队，文章以数据密集、推理克制著称。性能圈几乎人手一份他的两篇旧作：一篇是《Computer latency: 1973–2017》，实测发现 1977 年 Apple IIe 从按键到屏幕显示的延迟约 30 毫秒，而三十年后大量现代设备与软件反而超过它（来源）；另一篇是《In defense of simple architectures》，用真实系统证明「简单架构」的性能上限远高于大多数人的想象。
新作标题本身就是论点：软件慢已经没有任何借口。围绕这条主线，HN 上的讨论基本沿着经典轨道展开，当单机硬件性能翻了成百上千倍之后，这些性能到底被花在了哪里？
一笔不难算的账
其实早在 1995 年，Pascal 之父 Niklaus Wirth 就给出过答案：「软件变慢的速度，快过硬件变快的速度」，后人称之为 Wirth 定律。三十年后，这笔账反而更好算了：主流设备的单核性能、内存容量与 SSD 带宽相比上世纪已是数量级的差距，但聊天应用吃掉上 GB 内存、网页首屏加载几十 MB、一次 npm install 拉回半 GB 依赖，仍是日常景观。性能从来不是被用掉的，而是被散漫地漏掉的。
反例也确实存在。Figma 把多人协作的同步运算从 TypeScript 换成 C++ 并编译到 WebAssembly，吞吐量提升数倍（来源）；SQLite 用几十年打磨出「几乎不会成为瓶颈」的名声；我们此前也介绍过 LiteLLM 重写网关热路径的故事，同样是以小团队拿到大数量级收益的样板。这些案例的共性是：性能问题最终靠的是少数人认真对待，而不是等待硬件自然进化。
为什么没人做优化
真正的瓶颈多半不在技术，而在组织。至少有三层结构性原因：
一，记账方式偏了。「开发者时间比机器时间贵」从经验固化成了教条，但这本账只算了开发成本，没算全体用户在等待上付出的总时间。慢，是把成本摊薄到千万用户头上；优化，是把成本集中压到一个团队身上——从任何一张内部报表看，后者都更贵。
**二，激励机制偏了。**新功能有 demo、有发布时刻，性能优化「只是」让数字变小。如果一个延迟指标没有看板、没有负责人、不进考核，它的回归只是时间问题。
**三，延迟的代价其实早有定论。**亚马逊 2006 年的数据显示页面延迟每增加 100 毫秒，销售额约下降 1%（来源）；谷歌早期实验也发现 400 毫秒的延迟会显著降低用户搜索量。至于「速度不重要」的 A/B 结论，很多时候来自样本偏差，最敏感的用户早就流失了，剩下的自然测不出差异。
简短点评
两点观察。其一，AI 辅助编程并没有自动解决这件事，生成代码更快，不等于生成的代码更快，甚至可能在新的抽象层上继续膨胀；性能工程的经验反而可能变得更稀缺、更值钱。其二，这笔账正在 AI 推理基础设施上被重新清算：推理引擎的速度直接等于单位成本与毛利，LiteLLM 掀起的热路径改造恐怕只是开头。
说到底，Dan Luu 想说的从来只有一句话：慢不是一个无解的物理难题，而是一件没被排期的工作。既然慢大多是选择的结果，那快也可以是。