性能
對用戶來說，程序員按是交付軟件，提供一個清爽的用戶界面，避免系統死機常常比程序的性能更爲重要。
性能同代碼速度之間存在着很鬆散的關係。如果只是關注於代碼的運行速度，那麼這種工作有點顧此失彼。特別要當心放棄其他功能區讓代碼跑的更快。如果過分強調速度，程序的整體性能常常不升反降。
性能和代碼調整
程序需求：在花費時間處理性能問題之前，請想清楚是否在解決一個確實需要解決的問題。
程序設計：程序設計包括了單個程序的主要框架，主要包括程序如何被分解爲類。有時程序的設計會使一個高性能的系統難於實現。其他的一些設計則易如反掌。在設計框架時優先考慮整體性能，然後再爲單個的子系統、特徵和類設置要達到的資源佔用目標。
類和子程序設計：設計類和子程序的內部機制爲高性能的設計提供了另一個機會。在這一層次的處理中，是否選擇了合適的數據類型和算法將對性能產生重要影響。
同操作系統的交互：或許沒有注意到程序正同操作系統進行交互，因爲有時編譯器會生成系統調用，或是程序庫使用了未曾想到的系統調用。
代碼編譯：優秀的編譯器能將清晰的高級語言轉換爲經過優化的機器碼。
硬件：有時，最經濟也是最有效的提升程序性能的方法就是購買新的硬件設備。
代碼調整：是一種對正確代碼進行調整實踐，它可以使得代碼的運行更爲高效。
關於代碼調整
代碼調整的問題在於，高效的代碼並不一定就是“更好”的代碼。
一些無稽之談
1、在高級語言中，減少代碼的行數就可以提升生成的機器代碼的速度，或是減少其資源的佔用——錯誤：拋開代碼所具備的美感不談，高級語言代碼行數和程序最終的資源佔用和運行速度之間並無必然聯繫。
2、特定運算可能比其他的快，代碼規模也較小——錯誤：在討論程序性能的時候，沒有“可能”一詞的位置。應該實際地測量程序的性能，這樣才知道改動到底是提升還是降低了程序性能。在代碼調整的時候，應該將根據環境的變化重新進行測試和調整。
3、應當隨時地進行優化——錯誤：一種理論認爲，如果使每一個小子程序達到最快和最小，那麼程序也一定會非常小並且運行得很快。這樣得方法會對微觀範圍內的優化忙的不可開交，從而對整個系統全局性的重要優化視而不見。
4、程序的運行速度同其正確性同等重要——錯誤：對於特定類型的項目，運行速度或資源佔用是程序員需要重點考慮的問題。這種類型的項目比人們通常所認爲的要少，並且隨着時間的推移會越來越少。這類項目的性能風險必須通過初期的設計來規避。對其他項目而言，過早地優化則會對軟件的整體性能質量產生嚴重威脅，受到影響的甚至會包括軟件的性能。
何時調整代碼
程序員應當使用高質量的設計，把程序編寫正確。設計的模塊化要易於修改，這樣可以讓後期的維護工作變得很容易。程序正確完成之後，再去檢查系統的性能。如果程序運行遲鈍，那麼在設法讓它更快更小。除非你對需要完成的工作一清二楚，否則絕對不要對程序做優化。
常見的低效率之源
1、輸入/輸出操作，常見程序效率低下的根源之一就是不必要的輸入和輸出。如果可以選擇在內存中處理文件，就不要費力地通過磁盤、數據庫，或是跨越網絡訪問相同的文件。除非程序對空間佔用非常敏感，否則數據都應放在內存裏面進行處理。
2、分頁問題，引發操作系統交換內存頁面的運算會比在內存同一頁中進行的運算慢許多。
3、系統調用，如果性能對程序來說已經成了一個問題，那麼就應找出系統調用到底讓你付出了多大的代價。
4、解釋型語言，解釋型語言似乎應當爲系統性能所搜到的損害做出解釋，在機器代碼創建和執行之前，解釋型語言必須要處理每一條程序指令。
5、錯誤，程序性能的最終麻煩就是代碼中的錯誤。這些錯誤可能是沒有去調試代碼、忘了釋放內存、數據庫表設計失誤、輪詢不攢在的設備甚至超時，等等。
性能測量
經驗對性能優化也沒有太大的幫助。一個人的經驗或許來源於一臺老掉牙的計算機，或許來自於過時的語言或編譯器——在任何一種因素髮生改變後，所有的經驗之談也會成爲狗屁。除非對效果進行測量評估，否則永遠也無法確定某次優化所帶來的影響。如果沒有測量性能變化，那麼想當然的優化結果不過是代碼變得更晦澀難懂。
性能測量應當精確
應當分配給程序CPU時鐘來計算，而不是日期時鐘。否則，當系統從自己的程序切換到其他程序的時候，算到某個程序頭上的時間實際上是被其他程序佔用了。
