分析模板元程序編譯時間

Question

我正在使用大量編譯時計算的C++項目。漫長的編譯時間正在減慢我們的速度。我如何才能找出模板元程序中最慢的部分，以便優化它們？ （當我們有很慢的運行時間計算時，我有很多分析器可供選擇，例如valgrind的callgrind工具。所以我嘗試構建一個調試GCC並分析它編譯我們的代碼，但我沒有從中學到太多東西。）

我使用GCC和Clang，但歡迎提供任何建議。

我在Boost的網站上發現了profile_templates，但它似乎很薄，並且需要jam/bjam構建系統。如果你展示如何在非果醬項目上使用它，我會讓你滿意。 https://svn.boost.org/svn/boost/sandbox/tools/profile_templates/似乎計算實例化次數，而計算所花費的時間將是理想的。

_{我們的項目使用CMake，並且足夠小以至於只爲模板概要分析一起使用Jamfile就可以接受。}

Answer 1

自2008年以來，我一直在使用大量使用模板元編程的庫。真正需要更好的工具或方法來理解哪些消耗最多的編譯時間。

我知道的唯一技術是分而治之的方法，可以通過將代碼分離到不同的文件中，註釋掉模板定義的主體，或者通過在#define宏中包裝模板實例並臨時重新定義這些宏來不做任何事情。然後，您可以重新編譯該項目，並且可以在不使用各種實例的情況下縮小範圍。

順便提一下，將相同的代碼分成更多，更小的文件可能會使其編譯速度更快。我不只是在談論並行編譯的機會 - 即使是連續編譯，我仍然認爲它仍然更快。我在編譯我的庫時以及編譯Boost Spirit解析器時都觀察到了gcc中的這種效果。我的理論是，gcc中的一些符號分辨率，重載分辨率，SFINAE或類型推斷代碼相對於遊戲中的類型定義或符號數量具有O（n log n）甚至O（n^2）複雜度在執行單元中。

最終，你需要做的是仔細檢查你的模板，並分離真正依賴於類型信息的東西，然後在代碼中實際上並不需要的部分使用類型擦除和虛函數模板類型。你需要從頭文件中取出東西，並將其轉換爲cpp文件如果那部分代碼可以移動。在一個完美的世界中，編譯器應該能夠爲自己弄明白這一點 - 你不應該手動移動這些代碼來保存它 - 但這是我們今天編譯器的最新技術。

Answer 2

http://www.cs.uoregon.edu/research/tau/about.phphttp://www.cs.uoregon.edu/research/tau/about.php可能是您對模板實體感興趣的東西，它顯示了每個實例化花費的時間分解。其他數據包括每個函數被調用的次數，每個函數調用的特徵函數的數量以及每次調用的平均包含時間是多少

Answer 3

經典書籍C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond附帶了關於編譯時成本分析的20頁附錄。它有一個伴隨着CD的代碼，該代碼在附錄中生成了圖表。

另一篇論文是http://aszt.inf.elte.hu/~gsd/s/cikkek/profiling/profile.pdf，這也許對你有用。

另一個更勞動密集的方法是從編譯器輸出中計算每個類的number of instantiations。

Answer 4

我知道這是一個老問題，但有一個更新的答案，我想給。

有一個基於鏗鏘的項目集針對這個特定的問題。第一個組件是clang編譯器上的一個工具，它可以生成編譯期間發生的所有模板實例的完整跟蹤，並具有計時值和可選的內存使用計數。該工具被稱爲Templight，如這裏訪問的（目前需要編寫針對補丁鐺源代碼樹）：

https://github.com/mikael-s-persson/templight

的第二個組成部分是一個轉換工具，可以讓你轉換templight痕跡成其它格式，比如易於分析的基於文本的格式（yaml，xml，文本等）以及可以更容易可視化的格式，比如graphviz/graphML，更重要的是一個callgrind輸出，可以加載到KCacheGrind中以可視化檢查模板實例化的元調用圖及其編譯時成本，例如創建boost::container::vector的代碼段的模板實例化配置文件的屏幕截圖，並將其與std::sort ：

看看這裏：

https://github.com/mikael-s-persson/templight-tools

最後，還有一個相關的項目，創建一個交互式shell和調試器能夠以交互方式上下行走模板實例化圖：

https://github.com/sabel83/metashell