如何在visual studio 2008中優化建築速度

Question

有人可以給我提高視覺工作室2008的建築速度嗎？
我有一個大型項目，包含許多具有完整源代碼的模塊。 每次構建時，每個文件都會被重建，其中一些文件沒有被更改。 我可以阻止重建這些文件嗎？ 我打開屬性“啟用最小重建”/ Gm，但編譯器拋出此警告

Command line warning D9030 : '/Gm' is incompatible with multiprocessing; ignoring /MP switch

提高建築速度的每一個提示都會對我有所幫助。 謝謝，

Answer 1

對於超過一定大小的每個項目，C ++編譯時間都是一場戰斗。 幸運的是，有這么多人編寫大型C ++項目，有各種各樣的解決方案：

經典的廉價解決方案是“統一構建”。 這只是意味着使用#include將所有.cpp文件放入一個文件進行編譯。 這里有關於stackoverflow的一些問題，“Unity build”已經出現了， 這是我所知道的最突出的問題。 此截屏視頻演示了如何在Visual Studio中設置此類構建。

我的理解是，統一構建比經典構建快得多，因為它們有效地緩存了預處理器和鏈接器完成的工作。 統一構建的一個缺點是，如果你觸摸一個cpp文件，你將不得不重新編譯你的“大”cpp文件。 你可以通過打破你在Unity統一構建中迭代的cpp文件並自己編譯它來解決這個問題。

除了Unity構建之外，這里列出了我的最佳實踐：

• 僅在必要時使用#include ，更喜歡前向聲明
• 使用pimpl習慣用法將類實現保留在常用的頭文件中。 這樣做允許您將成員添加到實現，而無需長時間重新編譯
• 對於很少更改的常用頭文件，請使用預編譯頭文件（pch）
• 確保您的構建系統使用本地硬件上的所有可用內核
• 保留預處理器必須搜索最小的目錄列表，在#include語句中使用精確路徑
• 在頭文件的頂部使用#pragma once而不是#ifndef __FOO_H #define __FOO_H ... #endif ，如果你使用#ifndef技巧，編譯器必須在每次包含時打開頭文件， #pragma once允許編譯器更高效

如果你正在做所有這些（統一構建將產生最大的不同，根據我的經驗），最后一個選項是分布式構建。 distcc是我所知道的最好的免費解決方案， incredibuild是專有的行業標准。 我認為分布式計算將是從混亂的C ++編譯過程中獲得大量迭代時間的唯一方法。 如果您可以訪問相當多的機器（例如，10-20），這是完全值得研究的。 我應該提到統一構建和分布式構建並不是完全共生的，因為傳統的編譯可以分成更小的工作塊而不是統一構建。 如果你想分發，可能不值得建立一個統一版本。

Answer 2

Enable Minimal Build ： /Gm與Build with Multiple Processes不兼容： /MP{<cores>}
因此，您一次只能使用這兩個中的一個。

/ Gm>項目屬性： 配置屬性 > C / C ++ > CodeGeneration
要么
/ MP {n}>項目屬性： 配置屬性 > C / C ++ > 命令行

---

還要防止不必要的構建（未受影響的文件） - 正確構建代碼; 遵循以下規則：

在[ .h ]頭文件中， 只放置頭文件本身內容所需的內容;
以及您需要在多個執行單元之間共享的所有內容。

其余的都在實現[ .c / .cpp ]文件中。

Answer 3

一種簡單的方法是在調試模式下編譯（也就是零優化），這當然只適用於內部測試。

您還可以使用預編譯頭*來加速處理，或者將“不變”段拆分為靜態庫，從重新編譯中刪除它們。

*使用/MP你需要在進行多進程編譯之前創建預編譯頭，因為/MP可以讀取但不能根據MSDN寫入

Answer 4

更改一個頭文件后重建所有文件是一個常見問題。 解決方案是仔細檢查#include您的頭文件使用的內容，並刪除所有可以刪除的內容。 如果您的代碼僅使用指針和對類的引用，則可以替換

#include "foo.h"

同

class Foo;

Answer 5

您能否提供有關項目結構以及正在重建的文件的更多信息？
可以重建未更改的C ++文件，因為它們包含已更改的頭文件，在這種情況下/ Gm選項將無濟於事