[ACCEPTED]-How do I find out why g++ takes a very long time on a particular file?-g++

Won't give all the details you want, but 3 try running with the -v (verbose) and -ftime-report flags. The 2 latter produces a summary of what the compiler 1 has been up to.

It most probably includes TONNES of includes. I 3 believe -MD will list out all the include 2 files in a given CPP file (That includes 1 includes of includes and so forth).

What slows g++ down in general are templates. For 5 example Boost loves to use them. This means 4 nice code, great performances but poor compiling 3 speed.

On the other hand, 15min seems extremely 2 long. After a quick googling, it seems that 1 it is a common problem with mingw

I'd use #if 0 / #endif to eliminate large portions 5 of the source file from compilation. Repeat 4 with different blocks of code until you 3 pinpoint which block(s) are slow. For starters, you 2 can see if your #include's are the problem by using 1 #if 0 / #endif to exclude everything but the #include's.

Another process to try is to add "progress 11 marker" pragmas to your code to trap the portion 10 of the code that is taking a long time. The 9 Visual Studio compiler provides #pragma message(), although 8 there is not a standard pragma for doing 7 this.

Put one marker at the beginning of 6 the code and a marker at the end of the 5 code. The end marker could be a #error since 4 you don't care about the remainder of the 3 source file. Move the markers accordingly 2 to trap the section of code taking the longest 1 time.

Just a thought...

Related to @Goz and @Josh_Kelley, you can 9 get gcc/g++ to spit out the preprocessed 8 source (with #includes inline) using -E. That's 7 one way to determine just how large your 6 source is.

And if the compiler itself is 5 the problem, you may be able to strace the 4 compile command that's taking a long time 3 to see whether there's a particular file 2 access or a specific internal action that's 1 taking a long time.

What the compiler sees is the output of 18 the pre-processor, so the size of the individual 17 source is not a good measure, you have to 16 consider the source and all the files it 15 includes, and the files they include etc. Instantiation 14 of templates for multiple types generates 13 code for each separate type used, so that 12 could end up being a lot of code. If you 11 have made extensive used of STL containers 10 for many classes for example.

15K lines in 9 one source is rather a lot, but even if 8 split up, all that code still needs to be 7 compiled; however using an incremental build 6 may mean that it does not all need compiling 5 all the time. There really is no need for 4 a file that large; its just poor practice/design. I 3 start thinking about better modularisation 2 when a file gets to 500 lines (although 1 I am not dogmatic about it)

One thing to watch during the compile is 7 how much memory your computer has free. If 6 the compiler allocates so much memory that 5 the computer starts swapping, compile time 4 will go way, way up.

If you see that happen, an 3 easily solution is to install more RAM... or 2 just split the file into multiple parts 1 that can be compiled separately.