讓常見情況變快(make the common case fast)
假設你正在重新設計一座繁忙的機場。你可以把全部預算花在替很少用到的貨運航廈鍍金,也可以拓寬每一位旅客都要排的安檢線。明智的選擇顯而易見:改善發生最頻繁的那件事,因為時間實際就花在那裡。「讓常見情況變快」就是把這個原則用在電腦上——找出機器最常做的事,把心力灌注在那裡。
具體來說,這條架構的指導原則是:找出頻繁、簡單的事件並優化它們,即使代價是讓罕見、複雜的事件稍微慢一點。加法器被設計成在加兩個正常數字這個極其常見的情況下很快,而那些奇異的角落情況可以多花幾個週期。快取讓常見情況——存取你最近用過的資料——很快,而罕見的快取未命中則付出沉重代價。其根據是定量的,直接來自 Amdahl 定律:你能省下的時間正比於某情況發生的頻率乘以你把它加速的幅度,所以對發生 90% 時間的事做適度改進,勝過對只發生 1% 時間的事做驚人改進。
誠實的告誡是:「常見」必須測量,不能用猜的。程式設計師出了名地不擅長預測自己的程式把時間花在哪;真正的熱點往往出人意料。所以這條原則有個夥伴:先剖析,再優化。加速一條罕見路徑感覺很有生產力,卻幾乎完全撼動不了整體數字——這正是 Amdahl 定律警告的陷阱。這項紀律就是讓量測、而非直覺,告訴你哪個情況常見,然後把那一個變快。
剖析顯示一個程式 80% 的時間花在某個內層迴圈、20% 花在其他各處。把那個迴圈加速 2 倍:新時間 = 0.20 + 0.80/2 = 0.60,加速比 1.67。改成把所有罕見的程式碼加速 2 倍:新時間 = 0.80 + 0.20/2 = 0.90,加速比只有 1.11。常見情況勝出。
同樣是局部 2 倍加速,整體結果卻天差地別——因為套用在不同比例的時間上。
優化前先測量。對時間花在哪的直覺並不可靠;你「以為」很慢的那條罕見路徑可能對總執行時間毫無影響,在那裡下的功夫會被 Amdahl 定律白白浪費。