效能優化再議

有關效能優化，我們都知道」過早的效能優化是程式設計中的萬惡之源（donald knuth）」，因為效能優化可能打破程式的可讀性、可維護性甚至正確性，所以在進行效能優化的時候必須三思而後行。

在效能優化之前我們必須清楚的了解到了效能的問題確切發生在什麼位置，如果不知道哪些地方出問題就開始修理可能會導致大的時間浪費。

舉上段時間的乙個bad case，我們的程式發現效能上的問題，簡單review**後，我立刻發現有個優化的方案，但是幾乎要重構一部分的**，並且增加了整個**的複雜度。花了兩天的時間終於搞好了，執行了下發現效能提公升有限。再仔細一看，以前**的有個地方邏輯有問題，導致了這兩個版本的都存在效能問題。花了兩分鐘修改好後，發現第乙個版本效能也已經可以接受，並不需要那個新的版本。沒有仔細的分析問題瓶頸導致了白白浪費了兩天的開發時間。所以分析效能問題，就像醫生要治牙痛一樣，一定要找到導致問題的根源，不要拔光了牙才發現疼的是哪一顆。