我正在做一个大型项目，大多数文件超过7000行。如果我使用-fno-inline选项，则编译时间将减少3倍。
实际数字：
w / o -fno-inline-340秒
w / -fno-inline〜115秒
我没有发现有关-fno-inline对编译性能的影响的任何信息。 对此有任何解释吗？
一些背景：
我使用和不使用（-pipe，-O0到-O3，-g / no -g，-ggdb / no ggdb）测试了编译时间。没有什么比-fno-inline更能缩短编译时间了。
答案 0 :(得分：1)
我正在做一个大型项目，大多数文件超过7000行。
那有点大。通过避免大于5KLOC的文件（通过拆分多个大于8KLOC的大型C ++文件），以及并行编译 几种翻译，您可能（我不确定）会赢得一点编译时间单位（使用make -j或ninja）。这需要一些重构工作。另一方面，对于正版C ++，文件不要太小（因为诸如<vector>之类的标准容器头可能包含成千上万行；您可能还考虑将having作为预编译头）。实际上，每个C ++源文件3KLOC到7KLOC是一个很好的折衷方案。
使用-ftime-report option至g++获取每个编译阶段（或通过）的详细时间安排。您可能需要了解GCC的内部知识才能解密所获得的表。
我没有发现有关-fno-inline对编译性能的影响的任何信息。有什么解释吗？
Inline expansion在GCC内发生了几次 。它通常适用于某些GIMPLE或SSA内部表示。当然，内联可提高程序的运行时性能。禁用它可能会导致可执行文件失去50％的速度（甚至可能更多，因为内联成员函数（如getters and setters在C ++中已广泛使用，尤其是在标准container模板中）。
FWIW，我以前的GCC MELT网页（GCC MELT现在是一个沉寂的项目）有几个slides和参考资料，说明了GCC的内部结构，我现在（2018年10月）撰写>有关bismon的技术报告的草稿（目前由CHARIOT H2020项目资助）； draft恰好有第1.3.2节，解释了一些有趣的GCC优化。
另请参阅CppCon 2017演讲：Matt Godbolt “What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid”