大型项目的 C# 编译时间（与 C++ 相比）答案

【问题标题】：C# compilation time for large projects (compared to C++)大型项目的 C# 编译时间（与 C++ 相比）
【发布时间】：2013-10-13 21:38:47
【问题描述】：

我经常听到人们称赞 C# 的编译速度。到目前为止，我只制作了一些小型应用程序，而且确实我注意到编译速度非常快。但是，我想知道这是否仍然适用于大型应用程序。大型 C# 项目的编译速度是否比类似大小的 C++ 项目快？

【问题讨论】：

我也有同样的疑惑。我用 C# 编译了一个小应用程序，与 C++ 相比，编译速度快得惊人。
我开发了一个解决方案，其中包含 40 多个项目（我没有创建它），在 PIV 上编译需要很长时间（大约 1 分钟）。将我的 PC 升级到 Core 2 将其缩短到更可接受的时间，将代码重构为更少的项目也是如此。项目过多会影响 C# 项目的编译时间。

标签： c#

【解决方案1】：

是的，C# 通常编译速度要快得多。但并不总是足够快。我最大的 C# 代码库大约有 100 万行代码和很多项目，编译需要大约一个小时。但我怀疑大部分时间是由于视觉工作室糟糕的构建系统。另一方面，C++ 的编译时间通常要长得多，但也更多地取决于您如何组织代码。头文件依赖关系处理不当很容易将编译时间增加几个数量级。

【讨论】：

+1 评论糟糕的头文件处理 - 通过整理头文件，我们将大型 C++ 项目的时间从 1 小时缩短到 8 分钟！

【解决方案2】：

C++ 编译起来很慢，因为每次包含头文件时都必须重新读取和重新解析它们。由于“#defines”的工作方式，编译器很难自动预编译所有头文件。（Modula-2 在这方面做得更好）在许多 C++ 项目中，为每个编译的 C++ 文件读取 100 个标头是正常的。

有时增量 C++ 编译可能比 C# 快很多。如果您的所有 C++ 头文件（和设计）都处于非常好的状态（参见诸如 Large-Scale C++ Software Design、Effective C++ 之类的书籍）您可以更改大多数系统使用的类的实现，并且仅重新编译一个 dll。

由于 C# 在更改类的植入时没有单独的头文件，因此即使类的公共接口没有更改，该类的所有使用都会重新编译。这可以在 C# 中通过使用“基于接口的编程”和“依赖注入”等来减少。但它仍然是一个痛苦。

但总的来说，我发现 C# 的编译速度足够快，但大型 C++ 项目的编译速度太慢，以至于由于重建时间的原因，我发现自己不想向“基类”添加方法。

拥有大量 Visual Studio 项目，每个项目中包含少量类，这会大大降低 C# 构建速度。将相关项目组合在一起，然后“信任”开发人员不使用名称空间私有的类有时会带来很大的好处。（nDepends 可用于检查违反规则的人）

（在尝试加快 C++ 编译速度时，我发现 FileMon 非常有用。我从事的一个项目中，将 STL 添加到头文件中，构建速度变慢了很多。只需将 STL 添加到预编译的头文件中就可以了大不同！因此跟踪您的构建时间并调查何时变慢）

【讨论】：

+1 用于指出当您仅更改库的实现时，依赖项目需要重建的 C# 问题。 C++ 在将接口与实现明确分离方面做得更好，这实际上使其更适合大型项目。依赖注入只是一种解决方法，因为它强制整个代码库以兼容的方式重写，即它是侵入性的。
我们以什么数量级移动到那里？一个大项目的构建需要 1 秒、10 秒、100 秒？

【解决方案3】：

就我自己的经验而言，是的，C# 的编译速度比 C++ 项目快得多。即使是大型应用程序。

这可以通过以下事实来解释：C# 作为一种语言没有 C++ 复杂，并且 C# 被翻译成 IL（可以在以后进行优化和翻译成机器代码），而 C++ 被立即翻译成机器语言。

【讨论】：

【解决方案4】：

我还发现 C# 的编译速度明显快于 C++。主要原因之一当然是模板不需要位于 C# 的标头中，因为没有标头。但是大量使用模板（大多数是像 Boost 这样的现代 C++ 库）正在扼杀 C++ 中的编译时间。

【讨论】：