Jeff Dean给出反常答案：性能已经注定新智元

很多人背着「过早优化是万恶之源」的名言，写出的却是处处漏风的代码。Google传奇Jeff Dean的这份笔记破了真相：性能不是最后调出来的，而是你在选第一个容器、敲第一行代码时，就已经注定的物理结局。

2025年，是个很容易让人产生错觉的时间点。

这时算力不再稀缺，云资源随叫随到，AI已经能写出准确无误的代码。

在这样的环境里，「性能」似乎正在悄悄贬值。因为代码写得慢一些，好像也没什么大不了。

就在这种氛围下，Google的传奇工程师Jeff Dean更新了一份老文档：Performance Hints。

比起一篇炫技的论文，它更像是一份老派工程师的随笔，里面重新整理了基础法则。

它反复重申一个事实：计算机底层的物理规则，从未因为云原生、AI或硬件的进步而改变。

硬件的进步掩盖了代码的低效，这些问题会在系统中不断堆积，直到成为无法绕开的成本。

「过早优化」，成了平庸代码的豁免权

所有工程师都听过一句老话：

Premature optimization is the root of all evil.（过早优化是万恶之源）。

它原本是提醒我们，别为了抠几行代码，把系统搞成一团乱麻。

但在实践中，这句话慢慢变了味，成了一个免责口令——只要遇到性能质疑，一句「别过早优化」就能把所有问题挡回去。

结果走向了另一个极端：写代码时，性能被整体忽略。抽象可以多一层，数据可以多拷贝一次，API可以写得更「通用」。

瑞士奶酪模型：单个小漏洞没事，但是一层层叠加，对齐了会出大事

大家总觉得将来有profiler，等真慢下来再说。

可等系统上线，流量涌入，响应开始变拖沓，大家终于打开性能分析图，却发现屏幕上什么都没有。

没有一个函数占掉40%的时间，没有明显的性能热点。你看到的只有一张异常平坦的火焰图——每一层都慢一点，每一个看似无关紧要的选择，都给未来埋下隐患。

你很难指出哪里出了错，因为问题从一开始就没有集中出现——这正是Jeff Dean反复强调的一种模式。

性能不是被某个错误决定拖垮的，而是被一连串「看起来没问题」的决策慢慢稀释掉的。

一旦走到这一步，优化会变得异常昂贵，因为你失去了明确的下手点。

所谓「关键的3%」，指的从来不是写完代码后再去抠字眼，而是在写第一行代码时，就要避开那些虽然方便、但明显低效的路径。

这不只是技巧，更像一种素养。真正拉开差距的地方，往往发生在profiler还没派上用场之前。

5ns和5ms之间，隔着整个物理世界

如果说前面的区别发生在「已经来不及了」，那么接下来要说的是：「为什么我们会在一开始就走错路」。

事实上，很多工程事故并不是因为「不会优化」，而是因为对「慢」没有感觉。

在编辑器里，5ns和5ms看起来只是多了几个0。缩进一样，语法一样，在Code Review时看起来合理合规。

但在物理世界，这些数字根本不属于同一个尺度。

Jeff Dean在清单里列出了一张延迟对照表。一旦把这些数字还原成现实中的时间，很多所谓的设计直觉会当场崩塌。

L1缓存命中：约0.5ns，等于微观世界里的一次脉搏。

分支预测失败：5ns，是连续十次脉搏。

主存访问：50ns，相当于起个身，走下楼，取了个外卖。

随机磁盘寻址：10000000ns，相当于从北京一路走到了上海。

最早由Google工程师整理，Jeff Dean在多次演讲中用过这个思路

如果你的方案里出现了一次磁盘寻址，后面无论代码写得多优雅、逻辑多漂亮，在物理尺度上都已经输透了。

这就是顶级工程师脑子里的「物理地图」。他们本能地知道：哪些操作属于同一量级，而哪些操作一旦混进来，系统的节奏就彻底乱了。

这也是「信封背面估算」（Back-of-the-envelope calculation）的价值所在。

它是一次动手之前的排查：这个方案会触发多少次内存访问？有没有隐藏的分配？循环里会不会撞上网络IO？

如果答案里出现了一个不合时宜的量级，这个方案就应该被扔进垃圾桶。