性能真的不重要了嗎？Jeff Dean給出反常答案

新智元報(bào)道

編輯：傾傾

【新智元導(dǎo)讀】很多人背著「過(guò)早優(yōu)化是萬(wàn)惡之源」的名言，寫出的卻是處處漏風(fēng)的代碼。Google傳奇Jeff Dean的這份筆記破了真相：性能不是最后調(diào)出來(lái)的，而是你在選第一個(gè)容器、敲第一行代碼時(shí)，就已經(jīng)注定的物理結(jié)局。

2025年，是個(gè)很容易讓人產(chǎn)生錯(cuò)覺(jué)的時(shí)間點(diǎn)。

這時(shí)算力不再稀缺，云資源隨叫隨到，AI已經(jīng)能寫出準(zhǔn)確無(wú)誤的代碼。

在這樣的環(huán)境里，「性能」似乎正在悄悄貶值。因?yàn)榇a寫得慢一些，好像也沒(méi)什么大不了。

就在這種氛圍下，Google的傳奇工程師Jeff Dean更新了一份老文檔：Performance Hints。

比起一篇炫技的論文，它更像是一份老派工程師的隨筆，里面重新整理了基礎(chǔ)法則。

它反復(fù)重申一個(gè)事實(shí)：計(jì)算機(jī)底層的物理規(guī)則，從未因?yàn)樵圃?、AI或硬件的進(jìn)步而改變。

硬件的進(jìn)步掩蓋了代碼的低效，這些問(wèn)題會(huì)在系統(tǒng)中不斷堆積，直到成為無(wú)法繞開(kāi)的成本。

「過(guò)早優(yōu)化」，成了平庸代碼的豁免權(quán)

所有工程師都聽(tīng)過(guò)一句老話：

Premature optimization is the root of all evil.（過(guò)早優(yōu)化是萬(wàn)惡之源）。

它原本是提醒我們，別為了摳幾行代碼，把系統(tǒng)搞成一團(tuán)亂麻。

但在實(shí)踐中，這句話慢慢變了味，成了一個(gè)免責(zé)口令——只要遇到性能質(zhì)疑，一句「別過(guò)早優(yōu)化」就能把所有問(wèn)題擋回去。

結(jié)果走向了另一個(gè)極端：寫代碼時(shí)，性能被整體忽略。抽象可以多一層，數(shù)據(jù)可以多拷貝一次，API可以寫得更「通用」。

瑞士奶酪模型：?jiǎn)蝹€(gè)小漏洞沒(méi)事，但是一層層疊加，對(duì)齊了會(huì)出大事

大家總覺(jué)得將來(lái)有profiler，等真慢下來(lái)再說(shuō)。

可等系統(tǒng)上線，流量涌入，響應(yīng)開(kāi)始變拖沓，大家終于打開(kāi)性能分析圖，卻發(fā)現(xiàn)屏幕上什么都沒(méi)有。

沒(méi)有一個(gè)函數(shù)占掉40%的時(shí)間，沒(méi)有明顯的性能熱點(diǎn)。你看到的只有一張異常平坦的火焰圖——每一層都慢一點(diǎn)，每一個(gè)看似無(wú)關(guān)緊要的選擇，都給未來(lái)埋下隱患。

你很難指出哪里出了錯(cuò)，因?yàn)閱?wèn)題從一開(kāi)始就沒(méi)有集中出現(xiàn)——這正是Jeff Dean反復(fù)強(qiáng)調(diào)的一種模式。

性能不是被某個(gè)錯(cuò)誤決定拖垮的，而是被一連串「看起來(lái)沒(méi)問(wèn)題」的決策慢慢稀釋掉的。

一旦走到這一步，優(yōu)化會(huì)變得異常昂貴，因?yàn)槟闶チ嗣鞔_的下手點(diǎn)。

所謂「關(guān)鍵的3%」，指的從來(lái)不是寫完代碼后再去摳字眼，而是在寫第一行代碼時(shí)，就要避開(kāi)那些雖然方便、但明顯低效的路徑。

這不只是技巧，更像一種素養(yǎng)。真正拉開(kāi)差距的地方，往往發(fā)生在profiler還沒(méi)派上用場(chǎng)之前。

5ns和5ms之間，隔著整個(gè)物理世界

如果說(shuō)前面的區(qū)別發(fā)生在「已經(jīng)來(lái)不及了」，那么接下來(lái)要說(shuō)的是：「為什么我們會(huì)在一開(kāi)始就走錯(cuò)路」。

事實(shí)上，很多工程事故并不是因?yàn)椤覆粫?huì)優(yōu)化」，而是因?yàn)閷?duì)「慢」沒(méi)有感覺(jué)。

在編輯器里，5ns和5ms看起來(lái)只是多了幾個(gè)0?？s進(jìn)一樣，語(yǔ)法一樣，在Code Review時(shí)看起來(lái)合理合規(guī)。

但在物理世界，這些數(shù)字根本不屬于同一個(gè)尺度。

Jeff Dean在清單里列出了一張延遲對(duì)照表。一旦把這些數(shù)字還原成現(xiàn)實(shí)中的時(shí)間，很多所謂的設(shè)計(jì)直覺(jué)會(huì)當(dāng)場(chǎng)崩塌。

• L1緩存命中：約0.5ns，等于微觀世界里的一次脈搏。

• 分支預(yù)測(cè)失敗：5ns，是連續(xù)十次脈搏。

• 主存訪問(wèn)：50ns，相當(dāng)于起個(gè)身，走下樓，取了個(gè)外賣。

• 隨機(jī)磁盤尋址：10000000ns，相當(dāng)于從北京一路走到了上海。

最早由Google工程師整理，Jeff Dean在多次演講中用過(guò)這個(gè)思路

如果你的方案里出現(xiàn)了一次磁盤尋址，后面無(wú)論代碼寫得多優(yōu)雅、邏輯多漂亮，在物理尺度上都已經(jīng)輸透了。

這就是頂級(jí)工程師腦子里的「物理地圖」。他們本能地知道：哪些操作屬于同一量級(jí)，而哪些操作一旦混進(jìn)來(lái)，系統(tǒng)的節(jié)奏就徹底亂了。

這也是「信封背面估算」（Back-of-the-envelope calculation）的價(jià)值所在。

它是一次動(dòng)手之前的排查：這個(gè)方案會(huì)觸發(fā)多少次內(nèi)存訪問(wèn)？有沒(méi)有隱藏的分配？循環(huán)里會(huì)不會(huì)撞上網(wǎng)絡(luò)IO？

如果答案里出現(xiàn)了一個(gè)不合時(shí)宜的量級(jí)，這個(gè)方案就應(yīng)該被扔進(jìn)垃圾桶。

很多性能問(wèn)題并非「實(shí)現(xiàn)得不夠好」，而是選錯(cuò)了路徑。

一旦建立起這種尺度感，很多無(wú)意義的爭(zhēng)論就能一眼看穿。

反直覺(jué)的真相：Google大佬的代碼為什么看起來(lái)很「土」？

真正拉開(kāi)差距的地方，不在于「寫得多聰明」，而在于知道哪些地方「不值得聰明」。

翻開(kāi)這份Performance Hints，我們能發(fā)現(xiàn)一個(gè)反直覺(jué)的事實(shí)：沒(méi)有復(fù)雜的算法，很多改動(dòng)看起來(lái)都有點(diǎn)「土」。

但這些細(xì)碎的選擇，卻被Jeff Dean反復(fù)拿出來(lái)強(qiáng)調(diào)。

對(duì)內(nèi)存的節(jié)制

「尺度感」讓我們意識(shí)到分配內(nèi)存的珍貴，在實(shí)戰(zhàn)中，這種意識(shí)會(huì)轉(zhuǎn)化成對(duì)容器的極致考究。

為什么他們偏愛(ài)InlinedVector？因?yàn)樵诮^大多數(shù)場(chǎng)景下，它根本不碰堆內(nèi)存，數(shù)據(jù)直接躺在棧上。

這帶來(lái)的是實(shí)實(shí)在在的物理收益：少一次分配，多一次緩存命中。

同樣的，使用Arena（內(nèi)存池）也不只是為了管理方便，而是為了讓數(shù)據(jù)在物理內(nèi)存上變得連續(xù)，順應(yīng)CPU緩存的節(jié)奏。

對(duì)數(shù)據(jù)分布的尊重

所謂的Fast Path（快路徑），本質(zhì)上是承認(rèn)世界是不均勻的。99%的請(qǐng)求和輸入都比想象中普通。

如果堅(jiān)持讓每一次調(diào)用都走那條「最通用、最保險(xiǎn)」的路，實(shí)際上是在用極少數(shù)的邊緣情況，綁架絕大多數(shù)的正常流量。

清單里提到的UTF-8處理就是一個(gè)典型：現(xiàn)實(shí)中大量字符串其實(shí)只有純ASCII字符。

如果一上來(lái)就按完整的解析邏輯走，那每一個(gè)字節(jié)都在為萬(wàn)分之一的極端情況買單。

看一眼，是ASCII就直接放行——這種行為，建立在對(duì)數(shù)據(jù)規(guī)律的尊重之上。

對(duì)抽象成本的自覺(jué)

清單里舉了個(gè)例子：把Protobuf邏輯改成原生結(jié)構(gòu)體，性能提升20倍，讓很多人不安。

Protobuf確實(shí)解決了跨語(yǔ)言和版本演進(jìn)的難題，但便利從不是免費(fèi)的，每一層封裝、每一次解析，都是一筆隱蔽的「抽象稅」。

就像在透支信用卡，你可以盡情購(gòu)物，可一旦賬單寄來(lái)，就要付出相應(yīng)代價(jià)。

抽象并不會(huì)消失，只是被編譯器展開(kāi)，最終落實(shí)到一行行具體的實(shí)現(xiàn)上。

當(dāng)抽象層數(shù)不斷疊加，成本也會(huì)在底層被一并兌現(xiàn)。

這就是為什么他們建議在熱路徑里避開(kāi)不必要的層級(jí)、避開(kāi)那些「為了完整而完整」的設(shè)計(jì)。

目的是讓你清楚地意識(shí)到，你到底在為什么付費(fèi)。

頂級(jí)工程師關(guān)心的，從來(lái)不是如何寫出最聰明的代碼，而是如何避免那些本不該出現(xiàn)的開(kāi)銷。

當(dāng)你在敲鍵盤時(shí)，能對(duì)分配、分布、抽象成本保持警惕，很多性能瓶頸在發(fā)生之前，就已經(jīng)被擋在了門外。

想提高性能，就不能對(duì)代價(jià)視而不見(jiàn)

很多人把性能理解成一種階段性的工作：系統(tǒng)慢了，就開(kāi)始優(yōu)化；不慢，就先放一邊。

但讀完這份清單，你很難再這樣看待它。

Jeff Dean們反復(fù)強(qiáng)調(diào)的，其實(shí)不是「如何省下幾納秒」，而是「你是否真正理解自己正在使用的計(jì)算資源」。

CPU、內(nèi)存、緩存、磁盤......這些底層的物理規(guī)律并沒(méi)有因?yàn)樵圃駻I的流行而消失，它們只是被包裝得更抽象了。

頂級(jí)工程師之所以顯得從容，是因?yàn)樗麄兒苌僮叩健富饒?chǎng)」里：在寫第一行代碼時(shí)，他們就已經(jīng)避開(kāi)了那些注定昂貴的路徑。

這份Performance Hints讀起來(lái)不像教程，更像是一份肌肉記憶。它不要求你處處極限優(yōu)化，而是要求你在做決策時(shí)，不要假裝不知道代價(jià)。

也許真正的分界線一直是——當(dāng)你寫下一個(gè)循環(huán)、設(shè)計(jì)一個(gè)數(shù)據(jù)結(jié)構(gòu)、決定要不要多加一層時(shí)，腦海中是否浮現(xiàn)出那張時(shí)間和尺度的地圖。

一旦有了它，很多平庸的代碼，你就再也寫不下去了。

參考資料：

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

秒追ASI

?點(diǎn)贊、轉(zhuǎn)發(fā)、在看一鍵三連?

點(diǎn)亮星標(biāo)，鎖定新智元極速推送！