java warning 编译_关于性能：Java编译器警告会影响编译时间吗？

我有一个带有数千个编译器警告的原始项目(原始类型，不必要的@SuppressWarnings，未使用的导入等)-该项目包含约5000个Java源文件。 这些警告是否可能对编译时间有重大影响？

请注意：我很清楚，仅仅为了提高性能而放弃编译器警告并不是这样做的好理由。 我很想摆脱警告，使添加新代码，减少潜在的错误等变得更加容易。但是在这种情况下，我要问的是，如果存在大量警告，编译过程是否需要更长的时间。

为什么在您的情况下需要编译时间？

编译时间长得无法接受吗？如果您修复其中的一些，它会减少吗？

从逻辑上讲，如果编译是基于注释进行优化的，那将有所不同。如果编译代码基于注释过滤警告，即找到所有警告并忽略带有注释的警告，则不会有很大的不同。

@AndyTurner是的，编译时间太长(在60s左右)，这是无法接受的。很难衡量这种改进，因为我只能自动修复未使用的进口，而其他一些则需要在警告的基础上进行修复，这非常繁琐。我一直希望对它是否值得追求有一个明确的肯定/否定。

@QmunkE怎样生成5000个随机类而没有任何编译器错误(以及类似的相互依赖性)，并查看编译时间是否相似。

与可维护性成本相比，这无关紧要。如果计算机保持凉爽以使其保持最高速度，则它运行速度会更快。即机器的温度可能更重要。

没有; 不明显。 解决编译器警告的价值在于减少项目维护时间，即减少程序员的时间，而不是减少编译所花费的时间。 通过解决这些警告，您将对发生的事情有更清晰的了解，而不会迷失在警告的海洋中...

我知道确实是这种情况，但这并不能回答我的问题。目前，我正在尝试以我能做的任何方式来改善构建时间(它的速度慢得令人无法接受，任何增量的改进都会导致开发过程中生活质量的提高)

@QmunkE-如果您的构建时间过长，并且您询问解决警告是否可以解决该问题，则答案为"否"。修复警告可能会稍微缩短您的构建时间，但是长构建时间背后的实际问题仍然存在。我的回答只是反映了这种误解。您可以考虑在构建时间上寻求帮助，而不是这个关于警告的狭question问题...

我知道还有很多其他更有效的方法可以缩短构建时间-这是一个问题，即是否会产生任何影响-如果答案为"否"，则其为"否"，但您的答案无济于事-它没有回答这个问题。从维护的角度来看，我很清楚为什么拥有数千个编译器警告会很糟糕。

病态改写，使其更易于理解，@ QmunkE。

它不是要被理解，而是从字面上询问是否在代码中包含警告与否是否对编译时间有可衡量的影响。我不在乎减少警告的数量是否有其他好处(我已经知道这一点)，或者是否还有其他更好的方法来改善编译时间(我也知道这一点)。

Are these warnings likely to have any significant impact on the

compile time?

没有。

在对Jans答案的评论中，您写了

it's literally asking whether there is a measurable impact on

compilation time if your code contains warnings vs whether it doesn't

是的，会产生可衡量的影响，但影响可能很小。 此评论使我认为您在问两个不同的问题？

扬斯的回答，至少对我来说是绝对正确的。

Jans的回答肯定是正确的。但这原本根本不是一个有用的答案-它解决了摆脱警告的另一个原因(这通常更重要，对我而言只是无济于事)。我的问题的关键是："这些警告是否可能对编译时间产生重大影响？" -我只想知道。不知道为什么这么难理解。