我从某人那里听说,在代码中包含大量警告的大型项目的构建速度比包含少量警告的项目要慢得多(当然,编译器设置为具有高级别的警告敏感性)。
是否有任何合理的解释,或者任何人都可以分享他们对这个主题的经验?
最佳答案
开启 GCC编译器(例如,用于 C 的 gcc
或用于 C++ 的 g++
)警告确实会占用少量 CPU 时间。使用例如gcc -ftime-report
如果你想要编译器时序的详细报告。警告诊断确实取决于优化级别。
但优化(尤其是高级别的,如 -O2
或更多)比警告需要更多的时间。根据经验,优化的编译时间与编译单元的大小和最大函数的大小(例如 Gimple 指令数或 C 代码行数)的平方成正比。因此,如果您有巨大的函数(例如,某些生成的 C 代码中的一万行函数),您可能希望将它们拆分成更小的部分。
在 MELT 的早期(一个 GCC 插件和 GCC 实验分支 -GPLv3+ 许可 - 实现了一个 DSL 来扩展 GCC ,我已经开发并且仍在研究),它在 C 中生成了 huge 初始化函数(今天它是更少的情况下,初始化在许多 C++ 函数中被拆分;例如,参见 GCC 的 MELT 分支中的 gcc/melt/generated/warmelt-base.cc 作为示例)。那时,我绘制了编译 -O2
时间与该初始化函数的长度,并测量了编译时间与其长度。您也可以尝试 manydl.c代码。同样,最大函数长度的平方是一个实验测量,但可能由寄存器分配问题来解释。另外,J.Pitrat还观察到大量生成的 C 函数——由他有趣的 CAIA system- 正在耗尽编译器。
此外,还会输出警告,有时,如果您有大量警告,IDE 或读取编译器输出的终端可能会变慢。
当然,正如多次评论的那样,编译器警告是你的 friend (所以总是用例如gcc -Wall
编译)。因此,请改进您的代码,以免收到任何警告。 (特别是,初始化大部分局部变量 - 我通常初始化所有变量;因为如果可以证明它们无用,编译器可以通过删除一些初始化来优化)。
顺便说一句,您可以使用例如自定义 GCC MELT添加您自己的自定义警告(例如检查一些编码规则的一致性)。
此外,在带有奇怪模板的 C++ 中,您可能会编写几十行代码,这需要花费数小时来编译(甚至由于内存不足而导致编译器崩溃,请参阅 this question)。
注意。 2019 年,GCC MELT 死了,它的域名 gcc-melt.org
消失了,但网页被归档 here .
关于c++ - 大量警告会增加编译时间吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25382568/