家好，我是程序喵。

最近看了一本書《提高C++性能的編程技術》，這本書內容比較老，有些內容不太適合現在的編譯器，但里面很多內容還是值得我們學習的。

我這里整理出了自認為有用的條目分享給大家，希望對大家有所幫助，想了解具體內容的的朋友可以直接去看書哈。

我將這些內容分為了三大類別：

• 對象的創建與銷毀：主要介紹對象構造與銷毀的代價和臨時對象那些事。
• 函數調用：主要介紹內聯和虛函數及模板相關的知識點。
• 設計：如何設計并編寫出更高效的代碼。

下面是正文，越下面的內容越有用：

• 對象的創建與銷毀：
  • C++中對象的定義會隱式的執行構造函數和析構函數，這是有開銷的，對象的生命周期不是無償的，至少對象的創建和銷毀會消耗CPU周期。所以若非必要，不要隨便定義對象，要等到需要使用對象的地方再創建它。
  • 對象的創建或銷毀會觸發對父對象和成員對象的遞歸創建或銷毀，要當心復雜層次中對象的復合使用。它們使得創建和銷毀的開銷更加高昂。
  • 對象的拷貝是有開銷的，很多時候可以減少拷貝，考慮按引用或者指針傳遞和返回對象。
  • RVO可以省去創建和銷毀局部對象的步驟，從而改善性能。
  • 臨時對象會以構造函數和析構函數的形式降低一半的性能。在可能是“+、-、＊”或者“/”的地方，可以考慮使用=運算符消除臨時對象。
  • 編譯器必須初始化被包含的成員對象之后再執行構造函數體。必須在初始化階段完成成員對象的創建。這可以降低隨后在構造函數部分調用賦值操作符的開銷。在某些情況下，這樣也可以避免臨時對象的產生。
  • 將構造函數聲明為explicit，可以避免隱式轉換，一般這塊都會被列為項目的編碼規范，不符合這個規范是過不了code review的。
• 函數調用：
  • 絕大多數的性能優化是靠內聯做到的。
  • 內聯就是用方法的代碼來替換對方法的調用。（和宏是不是挺像）
  • 內聯通過消除調用開銷來提升性能，并且允許進行調用間優化。
  • 內聯也有缺點，尤其是濫用的情況下。內聯可能會使代碼量變大，而代碼量增多后會較原先出現更多的緩存失敗和頁面錯誤。
  • 為什么說虛函數慢？虛函數的代價在于無法內聯函數調用，因為這些調用是在運行時動態綁定的。唯一潛在的效率問題是從內聯獲得的速度（如果可以內聯的話）。
  • 模板比繼承提供更好的性能。它把對類型的解析提前到編譯期間，也可以認為這是沒有成本的。
• 設計：
  • 軟件性能和靈活性之間存在一種基本的平衡，太靈活的設計一般性能都不太好，你的設計只需在當前范圍之內足夠靈活就可以了。在完成同樣的簡單工作時，char*有時可以比string對象更有效率。
  • 引用計數想必大家都知道，有些場景中沒必要使用引用計數，使用的簡單的非計數對象即可，但是有些情況下，引用計數是個非常有用且有效的設計，尤其是在下述場景中：
    • 目標對象是很大的資源消費者。
    • 資源分配和釋放的代價很高。
    • 高度共享，好多對象共享同一資源
  • 最快的代碼是從不執行的代碼，可做以下思考：
    • 你打算使用該計算結果嗎？不打算使用就別浪費資源啦
    • 你現在需要該結果嗎？請在真正需要的時候再進行計算。在一些執行流程中有些結果永遠不會被使用，因此不必過早地計算
    • 你是否已經知道結果？那可以考慮結果重復使用，而不是每次都做計算
  • 有的時候可能無法繞開該計算，此時就必須完成它，那如何加快計算速度？可做
    以下思考：
    • 該計算是否過于通用？上面說過，沒必要過度設計，滿足需求即可。
    • 有些情況下有些考慮使用庫調用，有些庫調用比較靈活，有些庫調用性能比較高，考慮使用高效的算法和數據結構。
    • 盡量減少內存管理，這些調用的代價比較高。
    • 80-20原則，如果考慮所有可能的輸入數據，則可以發現20%的數據在80%時間里出現。因此，應當以犧牲其他不經常出現的場景為代價來提高典型輸入的處理速度。
    • 緩存、RAM和磁盤訪問的速度差異很明顯，可能有10倍以上的差異。應該多編寫緩存友好的代碼。
  • 有些計算只有在特定的if-else分支下才需要，所以沒必要過早計算，因為有可能它的計算結果不會被用到。
  • 定期清理不需要的代碼：大型軟件往往會變得錯綜復雜，雜亂不堪。混亂軟件的一大特點就是執行失效代碼（那些曾經用來實現某個目標，但現在已經不需要的代碼）。定期清理失效和僵死代碼可以增強軟件性能，同時對于軟件也是一種維護。
  • 考慮利用多處理器：
    • 將任務做分解：將大的任務分為小任務，使線程并發地執行這些小任務。
    • 縮小臨界區：臨界區應該只包含關鍵代碼，不直接操作共享資源的代碼不要放在臨界區內。
    • 減小鎖粒度：不要用同樣的鎖來保護所有資源，除非這些資源是同時更新的。
    • 讀寫鎖：讀多寫少可以考慮使用讀寫鎖。
    • 偽共享：不要在類定義里把兩個使用頻度都很高的鎖放太靠近，它們共享同一個緩存行可能觸發緩存一致性風暴。
    • 驚群現象：仔細分析您的鎖調用的特征。當鎖被釋放時，是所有的等待線程都被喚醒還是只喚醒一個線程？喚醒所有線程會威脅到應用的可擴展性。
  • 要使用的存儲器離處理器越遠，訪問所需的時間就越長。離處理器最近的是寄存器，雖然容量很少，但是速度很快。對寄存器的優化對程序的性能提升而言是極為有益的。
  • 上下文切換的開銷巨大，請盡量避免上下文切換。

打完收工。