從陳官辰大大那看到很棒這篇 “Always Measure One Level Deeper“ 關於效能優化方面的文章. (不太清楚為何手機可以直接閱讀而電腦需要權限, 建議用手機閱讀此篇)
以效能量測的角度來切入軟體效能與系統觀念, 以此來討論其所具有的專業程度, 軟體開發上的重要性, 常犯的錯誤, 以及應該抱有的原則. 個人也常犯下這些錯誤, 而且許多提醒與建議都相當實用.
常犯的錯誤:
1. 相信數字 (Trusting the numbers):效能量測的程式碼如同其他程式碼般容易有問題, 但這些錯誤不容易被察覺.
2. 猜測取代量測 (Guessing instead of measuring): 有經驗性的猜測通常是正確的, 並在效能估測指引方面發揮重要作用; 然而, 工程師對性能的直覺並不可靠.
3. 表面量測 (Superficial measurements): 許多工程師僅僅量測系統的最外層可見行為, 這是必要的但卻有所不足. 這會留下許多無法回答的問題.
4. 匆促 (Haste): 對於效能評估總是沒有留下足夠的時間. 正確評測所需的時間總是被低估. 採用快速的方法總是會產生許多(對效能問題上的)錯誤.
1. 相信數字 (Trusting the numbers):效能量測的程式碼如同其他程式碼般容易有問題, 但這些錯誤不容易被察覺.
2. 猜測取代量測 (Guessing instead of measuring): 有經驗性的猜測通常是正確的, 並在效能估測指引方面發揮重要作用; 然而, 工程師對性能的直覺並不可靠.
3. 表面量測 (Superficial measurements): 許多工程師僅僅量測系統的最外層可見行為, 這是必要的但卻有所不足. 這會留下許多無法回答的問題.
4. 匆促 (Haste): 對於效能評估總是沒有留下足夠的時間. 正確評測所需的時間總是被低估. 採用快速的方法總是會產生許多(對效能問題上的)錯誤.
高品質效能分析的關鍵:
1. 充份的時間 (Allow lots of time): 效能分析是一個包含混亂, 發現和改進的漫長過程. 效能分析包含了數個階段, 而每個階段可能需要幾天到幾週的時間.
2. 不要輕信電腦產生的數字 (Never trust a number generated by a computer): 消除錯誤的唯一方法是不相信每一次測量得到的數據，直到經過了仔細的驗證. 在被證明是無誤之前, 應該對測量數字保有存疑.
3. 使用直覺提出問題而非提出回答 (Use your intuition to ask questions, not to answer them): 直覺是很棒的事情. 隨著在某個領域所累積的知識和經驗, 將開始對系統的行為以及如何處理某些問題產生強烈的感受. 但是，很容易變得過度自信並認為直覺是絕對正確的.
4. 總是更深一層的量測 (Always measure one level deeper): 如果想了解特定層級的系統性能, 不僅要測量該層級但也必須更深一級地測量. 也就是說, 測量底層在更高階影響效能的因素.
1. 充份的時間 (Allow lots of time): 效能分析是一個包含混亂, 發現和改進的漫長過程. 效能分析包含了數個階段, 而每個階段可能需要幾天到幾週的時間.
2. 不要輕信電腦產生的數字 (Never trust a number generated by a computer): 消除錯誤的唯一方法是不相信每一次測量得到的數據，直到經過了仔細的驗證. 在被證明是無誤之前, 應該對測量數字保有存疑.
3. 使用直覺提出問題而非提出回答 (Use your intuition to ask questions, not to answer them): 直覺是很棒的事情. 隨著在某個領域所累積的知識和經驗, 將開始對系統的行為以及如何處理某些問題產生強烈的感受. 但是，很容易變得過度自信並認為直覺是絕對正確的.
4. 總是更深一層的量測 (Always measure one level deeper): 如果想了解特定層級的系統性能, 不僅要測量該層級但也必須更深一級地測量. 也就是說, 測量底層在更高階影響效能的因素.
文章最後提出了幾個實務上作法的建議. 值得一讀.
沒有留言:
張貼留言