4

编译我的项目需要很长时间，我想我想改进它的编译时间。我要做的第一件事是将编译时间分解为单个文件。

所以编译器告诉我例如：

boost/variant.hpp: took 100ms in total
myproject/foo.hpp: took 25ms in total
myproject/bar.cpp: took 125ms in total

然后我可以通过引入前向声明和/或重新排序来专门尝试改善占用时间最多的文件的编译时间，这样我就可以省略包含文件。

这个任务有什么东西吗？我正在使用 GCC 和 ICC (intel c++)

我使用 Scons 作为我的构建系统。

4

3 回答 3

2

您对处理与其他人使用的头文件不匹配的头文件所花费的时间有一个不同寻常的、古怪的定义。所以你可能可以做到这一点，但你必须自己做。可能最好的方法是gcc在strace -tt. 然后，您可以查看它何时打开、读取和关闭每个文件，从而了解它处理它们的时间。

于 2012-12-17T18:04:26.007 回答
2

您是否尝试过将构建作为一个整体进行检测？与任何性能问题一样，您认为的问题可能实际上并不是问题。 Electric Make是与 GNU make 兼容的 make 实现，它可以生成带 XML 注释的构建日志，进而可以用于分析 ElectricInsight 的构建性能问题。例如，ElectricInsight 中的“按类型划分的作业时间”报告可以大致告诉您构建中哪些活动消耗的时间最多，特别是构建中哪些作业时间最长。这将帮助你将你的努力引导到他们最有成果的地方。

例如：

在此处输入图像描述

免责声明：我是 Electric Make 和 ElectricInsight 的首席架构师。

于 2012-12-17T18:31:34.807 回答
2

重要的指标不是处理（无论这意味着什么）头文件需要多长时间，而是头文件更改并强制构建系统在所有依赖单元上重新调用编译器的频率。

与编译过程的所有其他步骤相比，编译器花在解析无用代码上的时间非常少。即使您包含整个不需要的文件，它们也可能在磁盘缓存中很热。预编译的头文件使这变得更好。

目标是避免由于头文件中不相关的更改而重新编译单元。这就是 pimpl 和其他编译防火墙等技术的用武之地。

而链接时间代码生成又名整个程序优化使事情变得更糟，因为它取消了编译时防火墙并重新处理整个程序。

无论如何，应该从构建日志、提交日志甚至文件系统中的最后修改日期中获得有关头文件有多不稳定的信息。

于 2012-12-17T18:13:10.007 回答