软件没有理由再慢了：LLM 把性能优化的门槛削掉了几千倍

原文来源：Dan Luu — 曾需要罕见技能组合的性能优化，现在任何人敲几句话就能做。优化的成本降了几千倍，以前"不值得做"的优化如今全都值得做——软件没有理由再慢了。

Dan Luu 最近看到一条病毒式推文，说那些抱怨 LLM 导致代码变慢变臃肿的人，等他们把一切用超优化汇编重写后就会被打脸。他在自己之前的文章里说过，我们还没到想用汇编写一切的地步，但 Nolan Lawson 关于测试的那句"你现在可以自己选择想要多少 bug"——正在性能领域变得越来越真。

触发这条思考的是一条评论："以前需要罕见技能组合的专业性能工作，成本已经下降了好几个数量级。" 过去需要一个人或一个团队、具备稀缺技能才能做的性能优化，现在任何能打几行字的人都能做。这意味着大量过去因为"太贵不值当"而放弃的优化——只有最大规模或最赚钱的项目才做得起的那种——现在全都进入了可行区间。

一个周末的 regex 引擎实验

上一篇文章里，Dan Luu 用 agent 循环了一个月来优化 regex 引擎性能，造出了 FRE（他的正则引擎），配套 rebar 基准套件。结果是 FRE 严重过拟合到 rebar——直到他们警告 agent 有一个留出（holdout）基准，agent 才把优化泛化到"表现尚可"。

一个有趣的细节：FRE 的原生 AOT 编译版本在长搜索上表现很好。按理说，可以一边让 ripgrep 跑普通匹配器，一边在另一个线程编译原生代码，编译完了切换过去——长查询整体性能会更好。短查询会因丢一个线程给编译而变差，但 Dan 更在乎 ripgrep 跑几十秒甚至几分钟的场景，而不是几秒就完的。

同样的思路，他用几分钟的人类时间做了这个实验：打了几句话，agent 就完成了对人类来说相当大的一块代码手术，并在真实的 ripgrep 查询上跑基准。对几个简单查询，长查询看到了 2-4 倍的性能提升。但大多数查询更复杂，在代表性的留出查询上，启用 AOT 的场景只得到约 7% 的加速——不惊人，但对"花几分钟打给 codex"来说已经不错了，而且它还在继续优化。

"优化的成本变便宜"意味着什么

Dan Luu 从 2025 年 11 月起就注意到这种优化成本骤降的趋势。他的例子：对游戏 AI 一无所知的他，尝试给 Azul 桌游构建一个 AI。结果成了该游戏的世界最强 AI——大幅度领先。从描述第二强 AI 的论文看，他的 AI 在"AI 侧"可能略好，但主要赢在优化上，尽管花的算力大概少了两个数量级，而且主要跑在他的笔记本上，对方用的是机器集群。

那个 AI 是单线程的，他的是多线程的。他有原生代码版本，还有一个"邪恶的共享 wasm 内存 + JavaScript 版本"，两个版本用两种完全不同的搜索架构（小快网络的 minimax 和更大网络的 MCTS），需要完全不同的多线程算法——手工做是个相当大的工程。而他让 LLM 基于它自己（错误的）推理选了几次多线程算法，然后自己花了 30 分钟读游戏 AI 的多线程算法资料，最终让 codex 重写了多遍。

他关于调试多线程算法经验的一段话很能说明问题：标准做法（从调试日志实现重放以复现非确定性 bug）过去可能要几天到一周的手工工作，而 agent 在循环里轻而易举就能做——"只是让它尝试重放日志，每次重放不完美就插入日志记录非确定性"。

以前"不划算"的优化，现在全划算了

Dan 有 CPU 微码、CPU 验证、搜索引擎索引优化的背景，他描述了过去常见的决策模式：看着一个优化想"这能提高 2% 性能，但要花 N 人天验证这个棘手的优化是否正确"，然后根据是否值得花时间来决定做不做。

现在这个 N 下降了一个巨大的因子——人力时间上经常是 1000 倍/10000 倍/1000000 倍，按美元成本算（计量费率下的 token 成本 vs 当年写搜索索引编译器的 Bing 工程师工资）大约 1000 倍——值得做的优化数量暴涨。同理，那些"不确定能否成功"的优化：以前他偶尔会看着一个不确定能不能提速的优化想"这要花 M 小时实现，才能获得足以猜测性能影响的测量"，现在这种优化也有大量值得尝试了。

回到游戏 AI 的例子：那个 AI 每速度翻倍约获得 100 Elo（比国际象棋多，大概因为平局很少）。仅加多线程就足以在大机器上碾压可比的 AI。再叠加 10-20 个"大多数人嫌麻烦不愿意手工做"的优化，强度差距巨大——手工写的 AI 想跟上已经不现实了。

一个性能工程师被模型碾压的实录

作为准备性能面试的一部分，Jamie Brandon 试了 Anthropic 现在公开的性能面试题。自己试完后，他让 Claude 从他停下的地方继续，结果好得多。回头看 Claude 做了哪些他没做的，他说很多优化"我也想到了，但还没做到"，而"其他的是疯狂的操作，除非我要在这上面干几周，否则永远不会尝试"。

Jamie 是个相当靠谱的性能工程师，也拿到了他想要的那份性能工作——但在一个定义良好的优化问题上，他对付不了一个好模型。Dan 补充说他自己也没试过那道题，但怀疑在可比的时间控制下自己也打不过。

面向特定工作负载的优化：新常态

Amazon 的 Marc Brooker 在回应 Dan 上篇文章时预测："适配特定工作负载而非工作负载类别的动态定制软件，似乎是非常可能的结果。"

这在 Dan 看来几乎是必然的。写这篇文章前，他没有任何框架或准备，就让一个 agent 针对他的 ripgrep 查询做了工作负载专用优化——启动只花了他约 2 分钟。优化在一组查询上跑，之后用另一组留出查询验证。首轮优化后，工作负载优化版在留出集上比标准 ripgrep 快 2%，而且还在继续变快。2% 对他本地 ripgrep 使用不算大事，但考虑到只花了几分钟，而且这些优化从他开始打字时就开始做了还在持续改进——这个 2% 他收下了。

更一般地，对 Marc Brooker 或 pgrust 的 Michael Malis 这样的人来说，合理的做法不止是一次性优化，而是和客户合作试点"用客户数据优化他们的系统"，然后推广给更多客户。而对个人项目来说，既然跑这些实验只需几分钟，随手折腾这类东西也完全合理。

附录里最有意思的观察：codex 到底在怎么用 ripgrep

Dan 附上了 codex 在他机器上跑 ripgrep 的查询分布，几个数字很说明问题：

• 模式长度中位数 55 个字符，p90 是 119，p99 是 229，最长 1,924——比人手敲的 grep 长得多。
• 交替分支（alternation arms）中位数 3 个，p90 是 8，p99 是 15，最长 87。
• 最长的正则大多是函数名/测试名的长交替，比如一段 30+ 行的 fn (hot_byte_compiler_is_generic_only...|...) 交替，来自 FRE 开发。
• 有些是搞笑的数字构造，比如把 :(?:1[3-9]|[2-9][0-9])[0-9]{2}: 展开成 90 个交替分支的写法——"这对人类来说可能很奇怪，但 agent 似乎老干这种事"。
• 查询耗时相当惊人：p99 接近 1 分钟，p999 接近 10 分钟，一个月内最大单次查询接近 2 小时！
• 94% 的模式只出现一次（和大量长查询一致）；文件搜索则有较高局部性，小文件很可能在内存里被反复搜。

结语：性能不再是一门专属技能

Dan 长期以来一直反对"写慢代码的开发者应该羞愧"的论调——大多数程序员不搞性能是合理的，从业务和就业市场角度看，让他们都去学性能优化本来就不现实。但今天情况变了："一个对性能一无所知、但会用 LLM 的人，通常应该能造出性能不错的软件。"

直接告诉 LLM"优化"，它经常会做一堆你必须抓出来的错误操作——但这是"有效使用 LLM"本身就带的问题。结果就是：获得像样的性能，不再是一门稀缺技能。

这个观察的深意在于：当"性能优化"从专家特权变成通用能力，软件行业的基本约束条件就变了。以前慢是被接受的常态，因为快太贵；现在快很便宜，慢就不再是"没办法"，而是"没选择"。而一旦用户开始习惯快，慢软件的容忍度会越来越低——这对每个开发者都是值得提前想清楚的事情。