Google 傳奇工程師 Jeff Dean 與 Sanjay Ghemawat 近期公開關於效能改善的內部技術文件，這份文件彙整兩人在 Google 多年來的程式碼效能調校經驗，內容涵蓋從開發思維到具體實作的建議，這份指南原本僅在Google內部流傳，如今正式對外開放，對於追求軟體效能的開發者來說，是一份極具價值的技術資料，可以協助大家在程式開發與維運上有一些能進步的方向和思維參考。
重視效能開發思維
許多工程師常引用電腦科學家 Donald Knuth 的名言指稱過早最佳化是萬惡之源，藉此忽略程式開發初期的效能考量，Jeff Dean 與Sanjay Ghemawat 在這份文件中特別澄清這段話常被斷章取義，Knuth 的完整原意是我們在 97% 的情況下應該忽略微小的效率問題，但絕對不能放棄那關鍵的 3%，這份指南正是聚焦於那關鍵的百分之三。
兩位大神級工程師指出，若在開發大型系統時完全忽視效能，最終會導致系統各處都出現效能流失，造成整體運作緩慢且難以找出具體瓶頸，他們建議在撰寫程式碼時，只要不嚴重影響可讀性或增加過度複雜性，應優先選擇執行速度較快的方案。
建立效能估算直覺
指南中強調工程師應具備效能估算的能力，也就是所謂的封底計算 （Back-of-the-envelope calculation，BotEC），透過估算硬體操作的成本，開發者能在實際撰寫程式碼前就先篩選出較佳的設計方案，為了協助工程師建立這種直覺，文件中列出一份更新版的硬體運算延遲時間表，讓開發者了解不同操作間的巨大差異。
根據這份資料舉的案例，讀取 L1 快取僅需零點五奈秒，而從固態硬碟讀取 1MB資 料則需一百萬奈秒，若從磁碟讀取同樣大小資料更需高達一千萬奈秒，這些基本資料的概念，能幫助工程師判斷哪些操作屬於昂貴成本，例如在設計快速排序演算法或網頁縮圖生成功能時，便能透過計算記憶體頻寬或磁碟讀取時間來預估系統效能，他們團隊就是這樣一點一滴地搾出效能，讓 Google 平台的系統在過去的時間內能夠持續有進步和穩定的成長。
善用評測工具與微基準測試
在進行最佳化之前，測量是絕對必要的步驟，這份指南也建議優先使用 pprof 等分析工具來取得系統效能的高層次概要，並在需要更深入細節時使用 perf 工具來跑，此外，建立微基準測試雖然有助於驗證我們在程式修改後去執行時的改善成效，但也需留意這個結果是否能代表真實系統的運作情境。
當 CPU 分析結果顯示平坦而無明顯熱點時，通常代表系統中已無顯而易見的效能瓶頸，此時工程師應關注更多其他的微小最佳化機會，例如改善迴圈結構，或重新檢視呼叫堆疊頂端的程式碼，積少成多也能帶來顯著的效能提升。
具體程式碼實作建議
文件中也提供多項具體的 C++ 程式碼建議，例如使用批次處理 API 來取代逐筆操作，以減少重複的呼叫成本，或是將計算結果快取起來供後續使用，此外指南也推薦使用 view 類型如 string_view 來減少資料複製，以及允許呼叫者傳入已預先分配的資料結構，避免底層函式重複進行記憶體配置，這些技巧或設計哲學都能夠讓程式與系統搭配實執行得更順利些。
這份由 Jeff Dean 與 Sanjay Ghemawat 撰寫的指南，不僅是技術層面的教學，更是一種工程思維的傳承，提醒開發者在設計與撰寫程式碼時建立效能直覺與量測為導向，視效能為系統品質重要的一部分。
CyberQ 觀察，隨著 AI 輔助程式開發的風潮和時代來臨，程式設計與系統架構規劃時，這份文件也提供了很好的概念思維建構，幫助更多人在新的時代中，把程式和系統打造得更好，而技術是與時俱進的，不同環境也會有不同的做法，能夠多看多聽多學習相當重要。
首圖由 Nano Banana AI 生成
