《软件慢是因为设计差，不是因为语言慢》

Sat, 31 Oct 2026 01:02:49 GMT

《软件慢是因为设计差，不是因为语言慢》

标签：
#软件工程 #性能优化
#性能瓶颈分析 #IO密集型 #Amdahl定律 #AI辅助优化 #系统设计 #语言选型误区

总结：
这篇文章反驳了“用 AI 把软件重写成 C/Rust 就能变快”的流行观点。作者的核心论点是：大多数真实程序是 I/O 密集型的，性能瓶颈在数据库、网络和磁盘等待上，语言本身的执行速度只占很小一部分；即使遇到 CPU 密集型热点，慢语言也早已通过调用 C 级库（如机器学习中的矩阵运算）把重活外包了出去。真正有效的提速来自重新设计——缓存、异步、并行、消除 N+1 查询——而不是逐行翻译代码。

文章要点：
1. 大多数真实程序（尤其是 CRUD 类应用）是 I/O 密集型的：一次请求可能 50% 的时间花在数据库查询上，重写语言最多只能优化另外那 50%，按照 Amdahl 定律，整体提速上限约为 1.5～2 倍，远达不到数量级提升。
2. 慢语言早已学会“外包”：Python 之所以能打机器学习这类 CPU 密集场景，是因为 NumPy 等库把矩阵运算下放到高度优化的 C/汇编甚至 GPU 上——如果程序 80% 时间在 GPU 上做矩阵乘，用 C 重写 Python 代码毫无意义。
3. Bryan Cantrill 2018 年的经典案例佐证“设计 > 语言”：他把精心优化的 C 程序移植到 Rust 时借用检查器处处碰壁，改用“Rust 朴素写法”后反而快 30%——原因是 Rust 内部默认用 B 树而非二叉搜索树，缓存效率更高。
4. 作者亲历的有效提速手段全部是设计层面的：缓存慢操作、异步化/后台任务、并行化、把 N 条 SQL 合成一条、用快查询替换慢查询、跳过不必要的操作——没有一条与语言速度有关。
5. 慢语言反而可能更利于优化：高层语言代码一眼就能看出程序在做什么，更容易发现 N+1 查询或可异步化的 API 调用；如果先重写成汇编，这些结构性问题反而难以察觉。
6. 少数真正 CPU 密集的热点（如 tiktoken 用汇编重写提速 5 倍）确实存在，但属于窄缝场景；而且这类提速往往也来自重新设计（去掉正则依赖），不是语言本身的功劳。
7. 给 AI 时代的实用建议：别指挥智能体“把它重写成 C/Rust 来提速”，而要让它去分析火焰图、定位热点、提出重设计方案——语言重写只在极少数不可再简化的 CPU 密集热点处才值得动用。

URL：https://seangoedecke.com/software-is-slow-because-of-bad-design-not-slow-languages/

Seangoedecke

Software is slow because of bad design, not slow languages

Many people are saying that AI will make software faster by rewriting it in faster languages, but this isn’t generally true. Most programs cannot be…

Amdahl定律 | 锤子前端

《软件慢是因为设计差，不是因为语言慢》