軟體開發效能優化經驗總結

效能優化是軟體開發過程中必不可少，但又很困難的工作。這裡是我長期對c/c++開發的效能優化的經驗總結。

效能優化必須遵循必要的原則進行。

優化前必須有個明確的目標。目標可以有近期的，中期的和遠期的。

並且目標必須是可達到，可量化的具體的值。

在任何優化前必須進行效能測試，得到的測試結果必須儲存下來。這些資料有如下用處：

效能優化的任何方法和嘗試，以及得到的測試資料都應該記錄下來。

效能測試在很大程度上實際就是壓力負載測試。對於這類的效能不需要盡可能的加大資料壓力，測試對應的效能。

另乙個必須要進行多次反覆的相同測試，並執行相關的數理統計計算。有些產品和流程只有執行幾百萬次才能真正說明效能。這個是非常重要的。

效能優化不是改變功能。

所以這些都應該基於重構的原則進行，這就意味這任何效能優化不能對上層客戶**造成影響。如果這是無法避免的，必須明確說明。

發現了熱點後，我們必須將從最大的耗時著手。

2/8原則有兩層含義：

所以我們不能盲目的優化，更不能以自己的推斷或者所為的「理論上是這樣的」想法執行優化，必須實事求是。

很多時候我們執行優化時是在

debug模式下執行的，但是最終我們形成

release模式下的效能資料。如果其中加入了為了記錄效能的

debug**，那麼在

release模式下必須關閉。

很多場景下，多是開發人員的效能測試指導效能優化。如果我們將整個流程自動化，那麼可以極大的提公升優化效率，更快發布。另外自動化最大的好處是可以將該過程嵌入測試人員測試過程，或者自動化測試

/整合/交付（

ci/cd）。

但是這是非常困難的，所以需要視情況而定。

我們的效能優化以及得到的結果必須是真實可信的，不能有半點作假和推測。

效能測試是我們優化的第一步。良好的測試方法是好的開始，而不良甚至錯誤的測試方法會得出錯誤的結果。

優化的方法有很多，但是這不意味著所有的方法在每個場景下都是可用的。

可以分為巨集觀和微觀兩個層次：巨集觀主要是基礎設施以及工程設計的優化，這個層面是不會對實現做很大變動的；而微觀則是對具體的編碼調整，內部調整可能會非常大。

在很多時候優化可能得出完全相反的結果，即效能反而更糟糕。這是非常正常的，優化路線可能很曲折漫長。有些熱點需要長時間嘗試不同的方法才能有效優化。

所以耐心和信心是優化過程中必備的良好心理素質。

遊戲開發效能優化經驗總結

優化概論 說起遊戲的優化，在遊戲開發中經常分為這幾步 首先要確定遊戲中經常會出現哪些問題 profile 然後確定在哪些方向進行效能優化 analyze 最後再盡可能將問題逐個解決 solve 遊戲開發中一定是先做工具，進行profile，再進行優化，所以，說優化就不得不再扯一下profile 常見...

《軟體開發效能優化系列》之死鎖

死鎖是由兩個相互阻塞的執行緒組成，它們互相等待對方完成，一般死鎖情況下兩個資料庫事務之間存在著相反的操作。sqlserver中死鎖監視器定時檢查死鎖，如果發現死鎖，將選擇其中回滾消耗最小的任務，這時候發生1025資料庫錯誤。可以通過啟用sqlserver2005快照模式，避免一些讀 寫的逆向阻塞造成...

《軟體開發效能優化系列》之Sql效能優化 一

對於一般簡單查詢，資料庫能自動引數啊以重用計畫快取，如 select from table where id 1 select from table where id 4 在sqlserver內部能自動引數化這個查詢，select from table where id 1 但是一旦sql語句中帶有...