从物理规则看性能优化：早期决策决定一切

许多开发者挂着“过早优化是万恶之源”的标语，却写出漏洞百出的代码。Google的传奇人物Jeff Dean在其笔记中揭示了真相：性能并非后期调试所得，而是在选择容器、编写首行代码的那一刻，已注定的物理宿命。

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

此时，算力不再稀缺，云资源随叫随到，AI已能编写无误的代码。

在这样的环境下，“性能”似乎正在悄然贬值。因为代码写得慢一些，似乎也没什么大不了。

然而，正是在这种氛围中，Google的传奇工程师Jeff Dean更新了一份名为《Performance Hints》的老文档。

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

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

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

“过早优化”，成了平庸代码的豁免权

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

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

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

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

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

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

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

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

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

性能不是由某个错误拖垮的

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

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

顶级工程师的“物理地图”

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

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

“慢”与“快”之间的物理世界

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

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

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

“信封背面估算”的价值

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

“土”代码背后的智慧

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

“数据分布”的尊重

“快路径”本质上是承认世界的不均匀。99%的请求和输入都比想象中普通。

“抽象成本”的自觉

“抽象税”是每一层封装、每一次解析的隐蔽成本。顶级工程师在热路径里避开不必要的层级和“为了完整而完整”的设计。