Link-Time Code Generation的優點和缺點是什麼？ （VS 2005）

Question

我聽說啓用鏈接時代碼生成（/ LTCG開關）可以是大量項目的主要優化，這些大型項目有很多庫鏈接在一起。我的團隊在解決方案的發佈配置中使用它，但編譯時間長是一個真正的拖延。對其他文件依賴的文件進行一次更改會觸發另外45秒的「生成代碼...」。發佈速度肯定比調試要快得多，但我們可以通過禁用LTCG並將O2/O2打開來實現相同的加速。

是否值得離開/啓用LTCG？

Answer 1

這很難說，因爲這主要取決於你的項目 - 當然用VS2005（我沒有與判斷足夠的經驗）提供的LTCG的質量。最後，你必須測量。

但是，我想知道爲什麼在發佈版本的額外持續時間中有這麼多問題。您應該只交出具有可重現或存檔來源的可重複，穩定，版本化的二進制文件。我很少看到頻繁增量發佈構建的原因。

一個團隊推薦的設置是這樣的： 開發人員通常只創建增量調試版本在他們的機器。構建發佈版應該是從源代碼管理到可再發行版（二進制文件或甚至設置）的完整版本，具有新版本號和標記/存檔來源。只有這些應該給予內部測試人員/客戶。

理想情況下，你將完整的構建移到一個單獨的機器，或者一個虛擬機一個不錯的PC機上。這爲您的構建提供了穩定的環境（包括第三方庫，環境變量等）。

理想地，這些構建應該自動化（「從源控制設置點擊」），並應每天運行。

Answer 2

我也沒有看到使用鏈接時代碼生成與發佈版本的額外編譯時間的問題。我每天只建立一次發佈版本（一夜之間），並在一天中使用單元測試和調試版本。

Answer 3

我知道在Bungie的傢伙用它HALO3，他們提到的唯一CON是，它有時會搞砸了自己的確定性重播數據。

你是否分析了你的代碼並確定了這個需求？實際上，我們幾乎完全在調試模式下運行我們的服務器，但特殊情況下有幾個文件被描述爲性能至關重要。這很好，並且在有問題時可以調試。

不知道你在做什麼樣的應用程序，但是分解數據結構以對應它們在代碼中處理的方式（以獲得更好的緩存一致性）對我們來說是一個更大的勝利。

Answer 4

它允許連接器來代碼的實際編譯，因此它可以做更多的優化，如內聯。

如果不使用LTCG，編譯器是構建過程中的唯一可以內聯函數的組件，例如用函數的內容替換「調用」函數，這通常是很多更快。無論如何，編譯器只會這樣做，以獲得改進。

因此，它只能使用它的主體。這意味着如果cpp文件中的某個函數調用另一個函數，該函數沒有在同一個cpp文件中實現（或者包含在頭文件中），那麼它沒有實際的函數體，因此不能內聯它。

但是，如果您使用LTCG，它是進行內聯的鏈接器，它具有整個項目的所有cpp文件中的所有功能，減去未使用LTCG構建的引用的lib文件。這使鏈接器（它成爲編譯器）有更多的工作要做。

但它也會讓你的構建花費更長時間，特別是在進行增量更改時。您可能想要在發佈版本配置中打開LTCG。

請注意，LTCG與輪廓引導優化不同。

Answer 5

我發現缺點是編譯時間更長，並且在該模式（LTCG打開）下製作的.obj文件可能非常龐大。例如，可能爲200-500k的.obj文件大約爲2-3mb。這只是發生在我身上，編譯我的鏈中的一堆項目導致了一個2 GB的文件夾，其中大部分是.obj文件。