是否有大量警告会使C＃编译时间更长？

我们有一个包含数千个警告的大解决方案。如果我删除所有警告（手动或使用工具），编译解决方案会花费更少吗？

我已经尝试将详细级别降低到无声，没有用。最大冗长级别也没有区别。

不，它不会对编译时间产生重大影响。与FX Cop等特殊工具不同，编译器本身不会执行任何复杂的检查，因此就其执行它的其他逻辑而言，这是无关紧要的。

在从命令行进行编译时，实际上可能会降低性能，从而将大量消息输出到控制台窗口中。在这种情况下，将输出重定向到文件是一种可能的改进。

但是，修复生成警告的代码部分是个好主意。您最终将获得更高质量的代码库，并减轻一些否则会更容易发生的错误。

更新：实验结果。

我们的代码库大约有。 34万行C＃代码在一个解决方案中分为48个项目。重新编译产生460个警告。编译器的输出长度为2800行，重定向到文件时占用近400 kB。

Core i7 920,9 GB RAM，单个7.2 krpm磁盘的编译速度：

所有时间都是三个编译的平均值，有一些初始编译强制文件进入缓存。请注意，我没有关闭警告进行任何测量。

你不应该沉默警告。大多数警告表示您的代码存在问题。您应该查看您的代码并修复它们。

处理所有警告应该花费编译时间（compieler需要向visual studio发送警告，更多警告应该意味着更多输出数据。但我不知道影响有多大）。但是，如果你修复警告，你也可以修复错误。

消除警告对编译时间没有影响。沉默会影响是否报告警告，而不是编译器是否检查所有规则或是否生成错误/警告。

正如Fox32所说，静音警告并不是一个好主意。如果你有太多的东西，那么代码就会严重错误。由于编译器必须处理更少的边缘情况，这也会使编译速度稍快。