GCC编译时间不会从预编译头文件中获益太多

我有一个庞大的项目，大约150 000个LOC的C++代码。建造时间约为15分钟。该项目由许多不同规模的子项目组成。GCC编译时间不会从预编译头文件中获益太多

我已经为每个子项目构建了单独的预编译头文件，但是当我使用它们时，构建时间保持大致相同。看起来，构建时间减少5-10％，而不是更多。

预编译头肯定是用，我用-Winvalid-pch选项，我试图与-H编译器选项来编译，我的预编译头出现在“砰”的标志，这意味着编译器能够使用预编译头输出。

我所有的预编译头文件都不是很大，每个文件大约50Mb。我使用python脚本，找到here来生成最常用的预编译头文件列表，所以我的预编译候选列表相当不错。

是否有任何免费/开源的构建优化工具？看起来，标准make实用程序没有能力测量不同目标的构建时间。我找不到用make获得不同目标统计数据的方法。我不是在谈论依赖关系分析还是先进的东西。我只想知道大部分时间里哪些目标被浪费了。

另外，看起来GCC在处理预编译头文件时效率很低。我无法让任何子项目的构建速度提高得更快，我得到的最大加速比为20％，这个项目需要三分钟才能完成。使用固态硬盘购买速度更快的机器似乎比使用GCC优化Linux上的编译时间要容易和便宜。

来源

2012-11-09 Lazin

尝试使用驻留在/ dev/shm中的源代码和输出目录来构建。如果构建时间急剧下降，那么之前的构建文件系统是构建时间的主要贡献者。 – bobah

我不会那么大。更像是一个中小型项目:) –

@BЈовић同意，但在我的机器上编译速度更快（或至少可比）。 – Lazin

如果您想充分利用此功能，您需要了解如何构建项目以充分利用它们。最好的方法是手动减少构建时间的缓慢，艰难的过程。听起来真的很愚蠢，但如果所有构建版本的速度提高5倍，并且知道如何构建项目和依赖关系，那么您就会意识到收益。

你可以设置你的目标，持续集成系统来测量，并为您的更改都在记录你的进步/改进。

我有一个庞大的工程，东西长约150 000 LOC的C++代码。建造时间约为15分钟。该项目由许多不同规模的子项目组成。

听起来像是做了大量冗余工作，假设你有一台现代化的机器。

也考虑链接时间。

我所有的预编译头文件都不是很大，每个文件大约有50Mb。

这是相当大的IMO。

我不是在谈论依赖分析还是先进的东西。

此外，统计的持续集成。对于构建缓慢，过度依赖很可能是问题（除非你有许多很小的cpp文件，或者像发生物理内存耗尽一样愚蠢）。

我无法得到任何子项目建设明显加快，最大加速，我得到的是20％

了解您的结构和依赖。 PCH放慢了我的大部分项目。

看起来，使用固态硬盘购买速度更快的机器比使用GCC优化Linux上的编译时间更简单，更便宜。

机会是，这台机器不会让你的编译时间快20倍，但修复你的依赖和项目结构可以使其快20倍（或任何问题的根源，最终是）。该机器只有这么多帮助（考虑到150KSLOC的构建时间）。

您的构建可能是CPU /内存绑定。

来源

2012-11-12 07:29:10 justin

它看起来像我有很多小cpp文件：'％find。 -name“* .cpp”| grep。 -c'返回846.此外，这个项目主要由两个大的静态库组成，其他项目相对较小，其中任何一个都比这些大的静态库小。其中一个静态库的大小为700Mb。并且代码库非常注重提升，例如它使用boost.spirit。 – Lazin

@Lazin嗯......每秒约1个文件对于您的项目大小和硬件来说可能并不那么糟糕。在我的系统上，clang的构建速度比gcc快 - 试试看吧。依赖分析和减少，http：//code.google.com/p/include-what-you-use/，也许团结构建。一旦相关性降低，那么您可以减少PCH包含的内容。还决定您是否可以重用PCH。所有这些cpp文件将推高目标文件大小和链接时间。在这种情况下，构建时可能会有很多I/O。当然，所有这些小文件都可能会推高冗余编译的数量。 – justin

由于BOOST_STATIC_ASSERT和其他一些事情，clang不会编译我们的项目。我将在稍后尝试此工具，它似乎会非常有帮助。谢谢！ – Lazin

GCC编译的时候没有太大的预编译头

是受益，不幸的是往往是真的，

有一些实验性的项目做的更好的东西，看到http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.html和http://gcc.gnu.org/wiki/pph，但他们还没有用。

我同意另一个答案，150KLOC 15分钟很慢。

我发现使用Gold链接器对构建时间产生巨大影响，我高度推荐它。

你也可以考虑ccache这可以帮助，如果你有空闲周期在其他机器上的慢磁盘distcc

避免建筑，当然避免网络磁盘。避免递归调用make，花更多时间读取makefile并重新创建依赖关系图。如果您可以构建子项目makefiles，以便它们都可以包含在单个顶级makefile中，那么非递归make需要一些时间才能开始，但是一旦它开始构建目标就会飞行。尽管如此，重写makefiles可能有很多工作要做。

它可能不言而喻，但建立在多核机器上，并使用make -j N，其中一个好的经验法则是N应该是核心数量的两倍，或者如果编译是I/O限制，则更多。

来源

2012-11-13 01:09:24

我试过ccache，现在重新编译速度非常快。我会尝试gold linker tomorow，谢谢你的建议。 – Lazin

我使用-include生成并使用PCH时包含一个包含大量标题的文件。它有帮助，但它仍然不那么令人印象深刻。

计算你的祝福，尽管：尽管MSVC有更好的PCH支持，但gcc似乎比MSVC快几倍。

来源

2012-11-13 04:13:57

GCC编译时间不会从预编译头文件中获益太多

回答

相关问题