軟體架構————代碼調整策略與技術

標籤：軟體   架構   效能最佳化   代碼調整   

效能

對使用者來說，程式員按是交付軟體，提供一個清爽的使用者介面，避免系統死機常常比程式的效能更為重要。

效能同代碼速度之間存在著很鬆散的關係。如果只是關注於代碼的運行速度，那麼這種工作有點顧此失彼。特別要當心放棄其他功能區讓代碼跑的更快。如果過分強調速度，程式的整體效能常常不升反降。

效能和代碼調整

程式需求：在花費時間處理效能問題之前，請想清楚是否在解決一個確實需要解決的問題。

程式設計：程式設計包括了單個程式的主要架構，主要包括程式如何被分解為類。有時程式的設計會使一個高效能的系統難於實現。其他的一些設計則易如反掌。在設計架構時優先考慮整體效能，然後再為單個的子系統、特徵和類設定要達到的資源佔用目標。

類和子程式設計：設計類和子程式的內部機製為高效能的設計提供了另一個機會。在這一層次的處理中，是否選擇了合適的資料類型和演算法將對效能產生重要影響。

同作業系統的互動：或許沒有注意到程式正同作業系統進行互動，因為有時編譯器會產生系統調用，或是程式庫使用了未曾想到的系統調用。

代碼編譯：優秀的編譯器能將清晰的進階語言轉換為經過最佳化的機器碼。

硬體：有時，最經濟也是最有效提升程式效能的方法就是購買新的硬體裝置。

代碼調整：是一種對正確代碼進行調整實踐，它可以使得代碼的運行更為高效。

關於代碼調整

代碼調整的問題在於，高效的代碼並不一定就是“更好”的代碼。

一些無稽之談

1、在進階語言中，減少代碼的行數就可以提升產生的機器代碼的速度，或是減少其資源的佔用——錯誤：拋開代碼所具備的美感不談，進階語言程式碼數和程式最終的資源佔用和運行速度之間並無必然聯絡。

2、特定運算可能比其他的快，代碼規模也較小——錯誤：在討論程式效能的時候，沒有“可能”一詞的位置。應該實際地測配量序的效能，這樣才知道改動到底是提升還是降低了程式效能。在代碼調整的時候，應該將根據環境的變化重新進行測試和調整。

3、應當隨時地進行最佳化——錯誤：一種理論認為，如果使每一個小子程式達到最快和最小，那麼程式也一定會非常小並且運行得很快。這樣得方法會對微觀範圍內的最佳化忙的不可開交，從而對整個系統全域性的重要最佳化視而不見。

4、程式的運行速度同其正確性同等重要——錯誤：對於特定類型的項目，運行速度或資源佔用是程式員需要重點考慮的問題。這種類型的項目比人們通常所認為的要少，並且隨著時間的推移會越來越少。這類項目的效能風險必須通過初期的設計來規避。對其他項目而言，過早地最佳化則會對軟體的整體效能品質產生嚴重威脅，受到影響的甚至會包括軟體的效能。

何時調整代碼

程式員應當使用高品質的設計，把程式編寫正確。設計的模組化要易於修改，這樣可以讓後期的維護工作變得很容易。程式正確完成之後，再去檢查系統的效能。如果程式運行遲鈍，那麼在設法讓它更快更小。除非你對需要完成的工作一清二楚，否則絕對不要對程式做最佳化。

常見的低效率之源

1、輸入/輸出操作，常見程式效率低下的根源之一就是不必要的輸入和輸出。如果可以選擇在記憶體中處理檔案，就不要費力地通過磁碟、資料庫，或是跨越網路訪問相同的檔案。除非程式對空間佔用非常敏感，否則資料都應放在記憶體裡面進行處理。

2、分頁問題，引發作業系統交換記憶體頁面的運算會比在記憶體同一頁中進行的運算慢許多。

3、系統調用，如果效能對程式來說已經成了一個問題，那麼就應找出系統調用到底讓你付出了多大的代價。

4、解釋型語言，解釋型語言似乎應當為系統效能所搜到的損害做出解釋，在機器代碼建立和執行之前，解釋型語言必須要處理每一條程式指令。

5、錯誤，程式效能的最終麻煩就是代碼中的錯誤。這些錯誤可能是沒有去調試代碼、忘了釋放記憶體、資料庫表設計失誤、輪詢不攢在的裝置甚至逾時，等等。

效能測量

經驗對效能最佳化也沒有太大的協助。一個人的經驗或許來源於一台老掉牙的電腦，或許來自於過時的語言或編譯器——在任何一種因素髮生改變後，所有的經驗之談也會成為狗屁。除非對效果進行測量評估，否則永遠也無法確定某次最佳化所帶來的影響。如果沒有測量效能變化，那麼想當然的最佳化結果不過是代碼變得更晦澀難懂。

效能測量應當精確

應當分配給程式CPU時鐘來計算，而不是日期時鐘。否則，當系統從自己的程式切換到其他程式的時候，算到某個程式頭上的時間實際上是被其他程式佔用了。

軟體架構————代碼調整策略與技術