我正在做一个大项目，大多数文件都超过 7000 行。如果我使用 -fno-inline 选项，编译时间会减少 3 倍。
实际数字:
无 -fno-inline - 340 秒
w/-fno-inline ~ 115 秒
我没有发现 -fno-inline 对编译性能的影响。 对此有什么解释吗？
一些背景:
- 我非常广泛地使用 MACROSes(用于记录目的)
- 有一个从旧代码继承的全局异常 try/catch block (需要重做这一 block )
- 里面很少有try/catch block ，主要是捕捉stof/stoi的异常
我用和 w/o(-pipe、-O0 到 -O3、-g/no -g、-ggdb/no ggdb)测试了编译时间。没有什么比 -fno-inline 更能缩短编译时间了。
最佳答案
I'm working on big project most files are longer than 7000 lines.
有点大。您可能(我不确定)通过避免大于 5KLOC 的文件(通过将大于 8KLOC 的大型 C++ 文件拆分为多个文件)以及通过并行编译多个翻译来赢得一些编译时间同时单位(使用 make -j 或 ninja )。这需要一些重构工作。另一方面，对于真正的 C++，文件不要太小(因为像 <vector> 这样的标准容器头文件可能包含数千行；您也可以考虑将 having 视为预编译头文件)。实际上，每个 C++ 源文件 3KLOC 到 7KLOC 是一个很好的权衡。
使用 -ftime-report option至 g++获得每个编译阶段(或通过)的详细时间。您可能需要了解 GCC 的内部结构才能破译获得的表。
I didn't find anything about -fno-inline impact on compilation performance. Is there any explanation to this ?
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”
关于c++ - -fno-inline 和编译时间，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52981361/