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看起来只是多了几个零。缩进相同，语法相同，在Code Review时看起来合理合规。

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

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

• L1缓存命中：约0.5ns，相当于微观世界的一次脉搏。
• 分支预测失败：5ns，等于连续十次脉搏。
• 主存访问：50ns，好比起身、下楼、取个外卖。
• 随机磁盘寻址：10,000,000ns，相当于从北京走到上海。

该对照表最早由Google工程师整理，Jeff Dean在多次演讲中引用过这一思路。

如果你的方案中出现了一次磁盘寻址，那么无论后续代码写得多优雅、逻辑多完美，在物理尺度上都已经输定了。

这就是顶级工程师脑海中的“物理地图”。他们本能地知道：哪些操作属于同一量级，而哪些操作一旦混入，系统的节奏就会彻底紊乱。

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

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

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

许多性能问题并非“实现得不够好”，而是选错了路径。

一旦建立起这种尺度感，许多无意义的争论便能一眼看穿。

反直觉的真相：Google大牛的代码为何看起来有些“土”？

真正拉开差距的地方，不在于“写得多聪明”，而在于知道哪些地方“不值得聪明”。

翻开这份Performance Hints，我们会发现一个反直觉的事实：没有复杂的算法，许多改动看起来都有点“土”。

但这些细碎的选择，却被Jeff Dean反复强调。

对内存的克制

“尺度感”让我们意识到分配内存的珍贵，在实战中，这种意识会转化为对容器的极致考究。

为什么他们偏爱 InlinedVector？因为在绝大多数场景下，它根本不触及堆内存，数据直接躺在栈上。

这带来的是实实在在的物理收益：少一次分配，多一次缓存命中。

同样，使用Arena（内存池）也不仅是为了管理方便，而是为了让数据在物理内存上连续分布，顺应CPU缓存的节奏。

对数据分布的敬畏

所谓的Fast Path（快路径），本质上是承认世界是不均匀的。99%的请求和输入都比想象中平凡。

如果坚持让每一次调用都走那条“最通用、最保险”的路，实际上是用极少数的边缘情况，绑架了绝大多数的正常流量。

清单中提到的UTF-8处理就是一个典型：现实中大量字符串其实只有纯ASCII字符。

如果一上来就按完整的解析逻辑走，那么每一个字节都在为万分之一的极端情况买单。

看一眼，是ASCII就直接放行——这种行为，建立在对数据规律的敬畏之上。

对抽象成本的清醒认识

清单中举了一个例子：将Protobuf逻辑改为原生结构体，性能提升20倍，令许多人不安。

Protobuf确实解决了跨语言和版本演进的难题，但便利从不是免费的，每一层封装、每一次解析，都是一笔隐蔽的“抽象税”。

就像透支信用卡，你可以尽情购物，可一旦账单寄来，就要付出相应代价。

抽象并不会消失，只是被编译器展开，最终落实到一行行具体的实现上。

当抽象层数不断叠加，成本也会在底层被一并兑现。

这就是为什么他们建议在热路径中避开不必要的层级、避开那些“为了完整而完整”的设计。

目的是让你清楚地意识到，你到底在为什么付费。

顶级工程师关心的，从来不是如何写出最聪明的代码，而是如何避免那些本不该出现的开销。

当你在敲击键盘时，能对分配、分布、抽象成本保持警惕，许多性能瓶颈在发生之前，就已经被挡在了门外。

想提升性能，就不能对代价视而不见

许多人将性能理解成一种阶段性工作：系统慢了，就开始优化；不慢，就先搁置。

但读完这份清单，你很难再这样看待它。

Jeff Dean们反复强调的，其实不是“如何省下几纳秒”，而是“你是否真正理解自己正在使用的计算资源”。

CPU、内存、缓存、磁盘……这些底层的物理规律并没有因为云原生或AI的流行而消失，它们只是被包装得更抽象了。

顶级工程师之所以显得从容，是因为他们很少走到“火场”里：在写第一行代码时，他们就已经避开了那些注定昂贵的路径。

这份Performance Hints读起来不像教程，更像是一份肌肉记忆。它不要求你处处极限优化，而是要求你在做决策时，不要假装不知道代价。

也许真正的分界线一直是——当你写下一个循环、设计一个数据结构、决定要不要多加一层时，脑海中是否浮现出那张时间和尺度的地图。

一旦有了它，许多平庸的代码，你就再也写不下去了。

参考资料：

https://x.com/JeffDean/status/2002089534188892256?s=20