|
|
本文是從 Don’t optimize! 這篇文章翻譯而來。
事實上你應該優化，但要在正確的地方，有足夠的理由。我待會兒再聊這個。
我最近和在 Badgerpunch Games 的幾位朋友一起發布了一個小的以XNA為基礎的游戲，而且通過論壇和Twitter與這個獨立的游戲開發組織保持密切的聯系。游戲開發者十分在意性能問題，而且這很必要。沒有人想要一個運行不暢的游戲。因為這些對性能的擔憂，出現了很多關于優化技巧的提示和論文，都圍繞著如何能實際有效的緩解性能問題。大多數的技巧提示和文章都提供了有價值的信息、有相應的用處，但你會發現很少有文章能觸碰到性能優化上的主要問題：什么時候不該優化，為什么。
優化就是這樣的事：你的程序可以一直優化下去，但工時上的開銷和取得的效果的對比會很快讓你陷入困境。我記起了九十年代早期在 Amiga Demo 公司的一幕。我大概花了半年的時間去優化那個3D旋轉的匯編程序片段。最終我覺得該優化的幾乎都優化了。起初幾周我努力減少CPU的指令循環，獲得了驚人的減幅！但隨后的數月里，我幾乎沒法再進一步的壓縮，最終只得放棄…我這段程序超級的快，可是，其他程序員的3D圖形跑的比我還要快，我無法理解，這怎么可能？
直到數年后我在大學里學了矩陣后我才明白其中的奧秘。我的程序里每個3D坐標用9次乘法，這是一個沒有優化的矩陣算法，它可以被壓縮成6次乘和兩個加法，這樣每個坐標點可以節省數百次的CPU指令循環…太郁悶了！
這個故事的寓意？你可以優化你的程序，讓它像星星一樣閃亮，但如果有人有更好的算法，讓同樣的程序跑的更快，你還是很失敗。
你很失敗嗎？只是在有意義的時候才能這樣說。在上面的性能優化的故事里，3D旋轉效果是被限制在一個16位的機器上的，這種情況下最快的程序證明了最出色的程序員，這時它的意義就很大了。
這讓我們回到了最初的那個問題。不要優化——如果優化是無關緊要的。重要的是讓你的代碼簡單易懂，容易修改！當你的程序具有這三個特征時，它是否被優化已經無關緊要了。
如果程序太慢，使用一個分析工具，找到什么地方需要優化。有時你并不需要一個分析工具，你只需要根據你的實際數據進行優化。當你找到了問題的區域，盡可能的用最簡單的方式修改它們，看看修改后有什么效果。最終讓你的程序達到到可以接受的性能程度。如果還不行，你需要根據你的代碼做算法上的修改。這就是為什么要保持代碼簡潔、易于修改的原因了。
讓代碼保持簡單易讀、易于修改的主要原因是為了尋找bug，這是一個閱讀和修改代碼的過程。程序越易懂，問題越容易修改。這是毫無疑問的…可是仍然有人堅持把事情能的盡可能的復雜，只是為了滿足個人的野心！我曾經看到一段Java代碼里有多層遞歸調用的if語句。這是一個最糟糕的無意識里做出的損毀程序的事。必然的，到處都是bug …看的我想哭。
另外一個保持代碼簡潔的原因是以最簡單的方式告訴編譯器你的程序的意圖。編譯器對簡單的代碼有更好的優化能力。如果你是一個虛擬機上使用JIT編譯器，這更顯的重要。虛擬機和按需編譯可以使你的程序能在不同的VM版本上運行。基本上虛擬機版本越新，你的代碼越簡單，當程序運行時，你就能獲得更好的優化結果。
早期版本的Java虛擬機做很少的編譯優化，所以像for循環、反向計數等技巧可以節省一些循環。但是最新版的編譯器和按需優化處理針對最常見的for循環形式進行了優化。性能問題從代碼轉移到了虛擬機上，長時間運行的程序在代碼上的優化技巧不再具有很重的份量。
所有的論述濃縮成這個：除非你知道優化什么，否則別去優化。這并不是說你不需要去考慮性能問題。你始終應該把性能問題放在心上。它有可能是你算法選擇上的問題，設計、實現上的問題，但你的主要精力應該放在保持代碼簡潔易讀，易于修改上。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
