1

I'm working on big project most files are longer than 7000 lines. If I'm using -fno-inline option compilation time going down 3 times. Actual numbers:
w/o -fno-inline - 340 sec
w/ -fno-inline ~ 115 sec

I didn't find anything about -fno-inline impact on compilation performance. Is there any explanation to this ?
Some background:

  • I use MACROSes pretty extensively (for logging purposes)
  • There is one global Exception try / catch block inherited from old code (need to rework this piece)
  • There are few try/catch blocks inside, mostly to catch exceptions from stof/stoi

I tested compilation time with and w/o (-pipe, -O0 to -O3, -g / no -g, -ggdb / no ggdb). Nothing brings compilation time so down as -fno-inline.

Ivan Kuchin
  • 99
  • 5
  • 1
    It'll reduce compilation time but it will also reduce run-time performance. – Jesper Juhl Oct 25 '18 at 04:32
  • Why does compilation time matter to you? Are you compiling in parallel several translation units (e.g. using `make -j` or `ninja`)? On which operating system are you compiling? How big is your entire project (milions of lines in hundreds of files?)? – Basile Starynkevitch Oct 25 '18 at 04:37
  • You could pass [the `-ftime-report` option](https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html) to `g++` to understand better where the compiler is spending its time. However, disabling inlining will lower significantly the run-time performance of your executable. – Basile Starynkevitch Oct 25 '18 at 04:41
  • 1
    "most files are longer than 7000 lines". Run away and don't look back. – n. m. could be an AI Oct 25 '18 at 05:40
  • @n.m: have you noticed that `#include ` expands to more than 15KLOC (at least on Linux, GCC8) ? – Basile Starynkevitch Oct 25 '18 at 07:45
  • 1
    @BasileStarynkevitch this is actually a pretty good indicator of the sad state of C++. Perhaps modules will change it. – n. m. could be an AI Oct 25 '18 at 08:36
  • @n.m: I agree with your comment (that C++ is in sad state). I am less optimistic than you are regarding its future. – Basile Starynkevitch Oct 25 '18 at 08:42
  • Thank you Basil and n.m. I want to reduce compilation time due to waiting about 5 mins for every compilation cycle is waste of time. make -j doesn't help if I have issue with single file file compilation. Looks like I need to refactor single file to multiple. Includes are more or less optimal in the project. – Ivan Kuchin Oct 25 '18 at 21:29

1 Answers1

1

I'm working on big project most files are longer than 7000 lines.

That is a bit quite big. You might (I am not sure) win a bit of compilation time by avoiding files bigger than 5KLOC (by splitting large C++ files, bigger than 8KLOC, in several ones), and by compiling in parallel several translation units at the same time (using make -j or ninja). This requires some refactoring work. On the other hand, with genuine C++, don't have too small files (because standard container headers like <vector> could include many thousands lines; you might also consider having a precompiled header). Pragmatically 3KLOC to 7KLOC per C++ source file is a nice trade-off in practice.

Use the -ftime-report option to g++ to get a detailed timing of each compilation phase (or passes). You may need to understand the internals of GCC to decipher the obtained table.

I didn't find anything about -fno-inline impact on compilation performance. Is there any explanation to this ?

Inline expansion happens several times inside GCC. It generally works on some GIMPLE or SSA internal representation. Of course, inlining is improving the runtime performance of your program. By disabling it, you could lose 50% of speed in your executable (and perhaps even more, since inline member functions such as getters and setters are extensively used in C++, notably in standard container templates).

FWIW, my old GCC MELT web pages (GCC MELT is now a dead project) have several slides and reference explaining GCC internals, and I am just writing right now (october 2018) the draft of a technical report on bismon (funded now by the CHARIOT H2020 project); that draft happens to have a section §1.3.2 explaining some interesting GCC optimizations.

See also CppCon 2017 talk: Matt Godbolt “What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid”

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547