我们有一个包含数千个警告的大解决方案。如果我删除了所有警告（手动或使用工具），编译解决方案会花费更少吗？
我已经尝试将详细级别降低到无声，没有用。最大冗长级别也没有区别。
答案 0 :(得分：20)
不，它不会对编译时间产生重大影响。与FX Cop这样的特殊工具不同，编译器本身不执行任何复杂的检查，因此就其执行它的其他逻辑而言，这是无关紧要的。
从命令行编译时，实际上可能会降低性能，从而将大量消息输出到控制台窗口。在这种情况下，将输出重定向到文件是一种可能的改进。
但是，修复生成警告的代码部分是个好主意。您将获得更高质量的代码库，并减少一些否则会更容易发生的错误。
更新：实验结果。
我们的代码库有大约。 34万行C＃代码在一个解决方案中分为48个项目。重新编译产生460个警告。编译器的输出长度为2800行，重定向到文件时占用接近400 kB。
Core i7 920,9 GB RAM，单个7.2 krpm磁盘的编译速度：
所有时间都是来自三个编译的平均值，有一些初始编译强制文件进入缓存。请注意，我没有关闭警告进行任何测量。
答案 1 :(得分：7)
你不应该沉默警告。大多数警告表示您的代码存在问题。您应该查看代码并修复它们。
处理所有警告应该花费编译时间（compieler需要向visual studio发送警告，更多警告应该意味着更多输出数据。但我不知道影响有多大）。但是，如果你修复警告，你也可以修复错误。
答案 2 :(得分：2)
使警告静音不会影响编译时间。沉默会影响是否报告警告，而不是编译器是否检查所有规则或是否生成错误/警告。
正如Fox32所说，静音警告不是一个好主意。如果你有太多的东西，代码严重错误。这也会使编译速度略快，因为编译器必须处理更少的边缘情况。