Jan Christiaan “JC” van Winkel

銀行的故事#

一家擁有多個分行的大銀行抱怨新購買的電腦太慢，櫃員等候時間過長，排隊人潮不斷增加，銀行甚至威脅要終止合約。效能分析師找到了元凶——一個消耗了幾乎所有 CPU 的函式，其原始碼如下：

for (i=0; i<strlen(s); ++i) {
    if (... s[i] ...) ...
}

每次迴圈迭代都呼叫 strlen 遍歷數千個字元來尋找結尾的空字元，但字串從未改變。只要事先計算長度，就能省下數千次不必要的呼叫：

n=strlen(s);
for (i=0; i<n; ++i) {
    if (... s[i] ...) ...
}

「先讓它動，再讓它快」的陷阱#

大家都知道「先讓它動，再讓它快」的格言，以避免微優化的陷阱。但上面的例子幾乎讓人相信那位程式設計師遵循的是「先讓它慢」的格言。

這種缺乏思考的情況比想像中更常見。新手程式設計師有時會不假思索地打字，突然間「發明」了 bubble sort，甚至還沾沾自喜。

選擇正確的資料結構#

選擇正確的演算法，另一面是**資料結構（data structure）**的選擇。當你要在一百萬筆資料中搜尋時：

• 使用 linked list：效能極差
• 使用 hash table 或 binary tree：效能大幅提升

這對使用者的感受有巨大影響。

務實的建議#

• 不要重新發明輪子，應盡量使用現有的函式庫
• 但要了解演算法的原理和擴展性，才能避免像銀行案例那樣的問題
• 程式設計師應該知道何時重用、如何重用，並對問題領域和演算法都有足夠的知識
• 也要知道何時使用「差勁的」演算法反而是對的——例如問題域保證最多只有五個元素時，bubble sort 可能就是最有效率的選擇

多讀好書並確保理解它們。如果你真的讀了 Donald Knuth 的 The Art of Computer Programming，甚至可能找到錯誤，贏得 Knuth 的十六進位美元支票（$2.56）。