當（執行時間）>>>（編譯時）時，多個編譯單元是否值得？

Question

根據我的理解，創建具有多個編譯單元的程序的主要好處是組件的可重用性和合並小變化時的較短編譯時間。

我也認為（可能錯誤地）存在與此相關的懲罰，因為在它們自己的編譯單元中定義的函數不能被聲明為“內聯”。
[我認識到這個關鍵字實際上不會強制編譯器內聯擴展函數，但我的理解是它為編譯器提供了更大的優化靈活性，因此值得盡可能包括在內。]

到現在為止還挺好？

我真正的問題是，當程序解決復雜的建模問題時，成本/收益分析是否仍然支持多個編譯單元，並且需要在集群上迭代其主循環數月才能生成有用的輸出。

假設一個多編譯單元程序需要幾分鍾來編譯，而同一個程序重新配置為單個編譯單元需要幾個小時來編譯...如果單個編譯單元將所有函數聲明為內聯，從而提供更多優化機會對我來說，期望執行時間減少幾個百分點，而不是彌補額外的編譯時間似乎是合理的。

對於像這樣的情況，是否有良好的經驗法則，還是嚴重依賴於情境？

Answer 1

一些編譯器/鏈接器能夠自動內聯函數，即使它們在一個編譯單元中定義並在另一個編譯單元中使用。 微軟的鏈接器當然可以做到這一點。

對我而言，將代碼拆分為單獨的編譯單元的主要好處是代碼的整體組織，我總是根據這個事實做出決定，而不是考慮你的考慮因素。 另外，不要忘記，較大的程序通常一次由多個人處理。 顯然，單獨的編譯單元是一個很大的好處。

總之，我認為這在很大程度上取決於情況。 我認為你的情況很罕見。

Answer 2

正如其他人所說，將程序分解為不同編譯單元的主要好處是可讀性。 較短的編譯時間在某種程度上是一個很好的副作用。

如果您關心內聯，則可以使用鏈接時間代碼生成和鏈接時優化 。 程序分解到編譯單元和LTO的組合看起來像是理想的解決方案，盡管尚不清楚當函數的完整定義可用時編譯器執行的優化類型是否可以由LTO執行。 例如，我不知道LTO是否可以支持C ++中的返回值優化，因為它是在高抽象級別完成的。 需要進行性能測試。 （ 編輯 ：RVO即使在沒有LTO和類似的高級技巧的情況下也會執行，至少在gcc和clang上[我試過]。很可能，這個優化是通過改變函數的ABI來執行的，它采用了“隱藏指針”到必須在函數中構造和返回的對象。）

值得研究的第三個解決方案是使用類似sqlite amalgamation的東西，這是一個將不同的編譯單元放入一個巨大的.c文件的過程。 雖然看起來像需要一個沉重的用戶制造基礎設施的東西。

Answer 3

不要忘記80-20規則。 80％的程序運行時花費在20％的代碼中。 也許你可以在一個編譯單元中擁有20％，其余的組織良好？

關於源組織，您仍然可以將算法放入標題（作為模板或內聯函數），然后從它們組成源。