家好，我是程序喵。

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

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

我將這些內(nèi)容分為了三大類別：

• 對象的創(chuàng)建與銷毀：主要介紹對象構(gòu)造與銷毀的代價和臨時對象那些事。
• 函數(shù)調(diào)用：主要介紹內(nèi)聯(lián)和虛函數(shù)及模板相關(guān)的知識點。
• 設(shè)計：如何設(shè)計并編寫出更高效的代碼。

下面是正文，越下面的內(nèi)容越有用：

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

打完收工。