GCC編譯時間不會從預編譯頭文件中獲益太多

我有一個龐大的項目，大約150 000個LOC的C++代碼。建造時間約爲15分鐘。該項目由許多不同規模的子項目組成。GCC編譯時間不會從預編譯頭文件中獲益太多

我已經爲每個子項目構建了單獨的預編譯頭文件，但是當我使用它們時，構建時間保持大致相同。看起來，構建時間減少5-10％，而不是更多。

預編譯頭肯定是用，我用-Winvalid-pch選項，我試圖與-H編譯器選項來編譯，我的預編譯頭出現在「砰」的標誌，這意味着編譯器能夠使用預編譯頭輸出。

我所有的預編譯頭文件都不是很大，每個文件大約50Mb。我使用python腳本，找到here來生成最常用的預編譯頭文件列表，所以我的預編譯候選列表相當不錯。

是否有任何免費/開源的構建優化工具？看起來，標準make實用程序沒有能力測量不同目標的構建時間。我找不到用make獲得不同目標統計數據的方法。我不是在談論依賴關係分析還是先進的東西。我只想知道大部分時間裏哪些目標被浪費了。

另外，看起來GCC在處理預編譯頭文件時效率很低。我無法讓任何子項目的構建速度提高得更快，我得到的最大加速比爲20％，這個項目需要三分鐘才能完成。使用固態硬盤購買速度更快的機器似乎比使用GCC優化Linux上的編譯時間要容易和便宜。

來源

2012-11-09 Lazin

嘗試使用駐留在/ dev/shm中的源代碼和輸出目錄來構建。如果構建時間急劇下降，那麼之前的構建文件系統是構建時間的主要貢獻者。 – bobah

我不會那麼大。更像是一箇中小型項目:) –

@BЈовић同意，但在我的機器上編譯速度更快（或至少可比）。 – Lazin

如果您想充分利用此功能，您需要了解如何構建項目以充分利用它們。最好的方法是手動減少構建時間的緩慢，艱難的過程。聽起來真的很愚蠢，但如果所有構建版本的速度提高5倍，並且知道如何構建項目和依賴關係，那麼您就會意識到收益。

你可以設置你的目標，持續集成系統來測量，併爲您的更改都在記錄你的進步/改進。

我有一個龐大的工程，東西長約150 000 LOC的C++代碼。建造時間約爲15分鐘。該項目由許多不同規模的子項目組成。

聽起來像是做了大量冗餘工作，假設你有一臺現代化的機器。

也考慮鏈接時間。

我所有的預編譯頭文件都不是很大，每個文件大約有50Mb。

這是相當大的IMO。

我不是在談論依賴分析還是先進的東西。

此外，統計的持續集成。對於構建緩慢，過度依賴很可能是問題（除非你有許多很小的cpp文件，或者像發生物理內存耗盡一樣愚蠢）。

我無法得到任何子項目建設明顯加快，最大加速，我得到的是20％

瞭解您的結構和依賴。 PCH放慢了我的大部分項目。

看起來，使用固態硬盤購買速度更快的機器比使用GCC優化Linux上的編譯時間更簡單，更便宜。

機會是，這臺機器不會讓你的編譯時間快20倍，但修復你的依賴和項目結構可以使其快20倍（或任何問題的根源，最終是）。該機器只有這麼多幫助（考慮到150KSLOC的構建時間）。

您的構建可能是CPU /內存綁定。

來源

2012-11-12 07:29:10 justin

它看起來像我有很多小cpp文件：'％find。 -name「* .cpp」| grep。 -c'返回846.此外，這個項目主要由兩個大的靜態庫組成，其他項目相對較小，其中任何一個都比這些大的靜態庫小。其中一個靜態庫的大小爲700Mb。並且代碼庫非常注重提升，例如它使用boost.spirit。 – Lazin

@Lazin嗯......每秒約1個文件對於您的項目大小和硬件來說可能並不那麼糟糕。在我的系統上，clang的構建速度比gcc快 - 試試看吧。依賴分析和減少，http：//code.google.com/p/include-what-you-use/，也許團結構建。一旦相關性降低，那麼您可以減少PCH包含的內容。還決定您是否可以重用PCH。所有這些cpp文件將推高目標文件大小和鏈接時間。在這種情況下，構建時可能會有很多I/O。當然，所有這些小文件都可能會推高冗餘編譯的數量。 – justin

由於BOOST_STATIC_ASSERT和其他一些事情，clang不會編譯我們的項目。我將在稍後嘗試此工具，它似乎會非常有幫助。謝謝！ – Lazin

GCC編譯的時候沒有太大的預編譯頭

是受益，不幸的是往往是真的，

有一些實驗性的項目做的更好的東西，看到http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.html和http://gcc.gnu.org/wiki/pph，但他們還沒有用。

我同意另一個答案，150KLOC 15分鐘很慢。

我發現使用Gold鏈接器對構建時間產生巨大影響，我高度推薦它。

你也可以考慮ccache這可以幫助，如果你有空閒週期在其他機器上的慢磁盤distcc

避免建築，當然避免網絡磁盤。避免遞歸調用make，花更多時間讀取makefile並重新創建依賴關係圖。如果您可以構建子項目makefiles，以便它們都可以包含在單個頂級makefile中，那麼非遞歸make需要一些時間才能開始，但是一旦它開始構建目標就會飛行。儘管如此，重寫makefiles可能有很多工作要做。

它可能不言而喻，但建立在多核機器上，並使用make -j N，其中一個好的經驗法則是N應該是核心數量的兩倍，或者如果編譯是I/O限制，則更多。

來源

2012-11-13 01:09:24

我試過ccache，現在重新編譯速度非常快。我會嘗試gold linker tomorow，謝謝你的建議。 – Lazin

我使用-include生成並使用PCH時包含一個包含大量標題的文件。它有幫助，但它仍然不那麼令人印象深刻。

計算你的祝福，儘管：儘管MSVC有更好的PCH支持，但gcc似乎比MSVC快幾倍。

來源

2012-11-13 04:13:57

GCC編譯時間不會從預編譯頭文件中獲益太多

回答

相關問題