軟件的優化得看使用的頻率，像一些軟件用戶不怎麼用，使用率並不高的這些軟件根本就沒有必要優化。而對於有些應用，軟件性能的不佳或許在每分每秒鐘能夠流失成千上萬個流量。因此工程師們爲了將系統的性能和流量哪怕提升一點點，都須要花費大量的時間。儘管在優化過程當中有許多的方法和技巧。但萬變不離其總，總有一些通用的技巧值的咱們去借鑑。性能優化
技巧1—老是建立基準用於比較函數
建立基準用於比較優化結果的必要性顯而易見，使人驚訝的是開發團隊經常在沒有任何基準的狀況下匆忙開展優化。基準測量很重要，由於每次優化獲得的改進會愈來愈小。舉例來講，第一遍能耗優化可能有20%的改進，第二次有10%，第三次5%，以此類推。開發人員應瞭解這種趨勢，並將他們在系統中得到的改進量化爲輸入次數的函數。工具
技巧2—設定優化目標性能
每一次優化都比前一次須要更多的時間才能從系統中得到極少許的改進。開發團隊須要仔細平衡他們的時間投入，並根據改進結果判斷是否值得花這麼多時間。一味悶頭作事很容易沉迷，可能花了數週時間才認識到本身在優化一個再也不須要優化的系統。所以在優化開始以前，開發團隊應設定一個目標值，達到這個目標，就表示優化結果對當前應用來講足夠好，優化過程已經完成。學習
技巧3—使用正確的測量工具測試
若是沒有合適的測量工具，優化一個系統是很困難的。舉例來講，若是不使用一種精確的方法來測量系統和微控制器的能耗，便很難完成能耗的優化。開發人員常常沒法區分這兩種不一樣的能量測量，他們試圖減小實際上沒法再減小的微控制器能耗。優化
對性能優化感興趣的開發人員能夠看一看我在「親自動手：Segger系統查看工具」中介紹的Segger系統查看工具，這款工具對於瞭解哪些 函數正在獨佔CPU很是有用。若是沒有可以精確測量或可供開發人員查看系統行爲的工具，那麼在優化系統時便抓不住重點。blog
技巧4—使用優化工具資源
爲了減少代碼大小或提升性能，嵌入式軟件的許多方面均可以優化。一些狀況下可使用獨立的或附屬的工具鏈。Somnium DRT優化器就是一種很好的優化工具，能夠與GCC一塊兒用來優化代碼大小、能量使用率和性能。開發
不過有時候外部工具可能不是必需的，只要選擇正確的工具鏈就足夠了。我最近寫了一篇題爲《開源與商用編譯器》的文章，說明了這樣一個事實：在Coremark測試中，對於相同的微控制器和相同的測試條件，商用編譯器的得分老是高於GCC等開源編譯器。
技巧5—使用編譯器屬性和#pragma指令
我通常很不喜歡用#pragma指令或編譯器屬性。屬性和#pragma指令一般是不可移植的，改變編譯器可能會形成軟件缺陷。然而，在調整嵌入式軟件時，開發人員一般沒有選擇。使用屬性和#pragma指令能夠提升速度，並能根據實際狀況有選擇地優化某個功能。基於這些理由，想要優化軟件的開發人員應該熟悉屬性的使用，並且要閱讀《用C語言編寫可移植的優化程序》，這樣他們才知道如何編寫出可移植的最優程序，而且沒有負面影響。
技巧6—多作實驗
在優化系統方面沒有一成不變的方法，開發人員不該該侷限於任何一種特殊的技術。有時候學習和優化系統的最好方法是嘗試各類實驗並分析其結果。
當我首次爲了低功耗而優化系統時，作了不少實驗，也出現了一些錯誤。經過實驗過程和所記錄的結果，我就可以理解什麼有用，什麼沒用，以及作哪些事是在浪費資源和時間。如何最好地利用printf就是一個簡單的例子： 經過嘗試不一樣的驅動模型能夠發現，不少方法均可以顯著提升開發人員使用printf時得到的實時性能，而人們設想的結果一般遠好於真實結果。
技巧7—深刻研究編譯器產生的指令
在資源特別有限的應用中，開發人員有時只需挽起袖子深刻理解編譯器產生的指令。在將要執行的三四個廣義指令間選擇三元操做符而不是if/else是有區別的，這極可能會致使應用程序崩潰。
雖然像C這樣的語言是標準的，但每種編譯器在優化和產生機器指令時有少量差別。惟一現實的方法是檢查彙編語言，瞭解編譯器在作什麼。
總結
各類應用程序的不一樣致使每種系統也是不一樣的。但這些系統的優化基本也都離不開以上7個步驟。只要開發人員按照這個步驟走，能夠說是離實現高效的系統優化又近了一步。