跟踪编译器以查看它在某些文件上花费了多少时间

Question

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

所以编译器告诉我例如：

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作为我的构建系统。

Answer 1

您对处理头文件所花费的时间有一个不寻常的，古怪的定义，与其他人使用的文件不匹配。所以你可能会发生这种情况，但你必须自己做。可能最好的方法是在gcc下运行strace -tt。然后，您可以看到它何时打开，读取和关闭每个文件，从而可以告诉它处理它们的时间。

Answer 2

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

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

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

链接时代码生成（又称整个程序优化）更糟糕的是，通过撤消编译时防火墙并重新处理整个程序。

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

Answer 3

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

例如：

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