Long building time in release configuration. is it normal?

[Andrey_P_]

Hello,

I use the latest Intel compiler atop MVS 2013. I am developing a small application which currently consists of a static library with main functionality (9 classes) and an one-file console executable to test the former. I decided to build the application under release configuration to find out how faster it will become.

The problem is while the static library builds rather swiftly producing 13 MB .lib file (that is,as I found out, normal), the executable is taking very long time. I left it overnight and it is still hasn't been finished (over 9 hours). There has been no visible progress except mcpcom has been slowly increasing its memory usage to currently almost  1GB.

The static library compiling settings :

/MP /GS /GA /W3 /Gy /Zc:wchar_t /Zi /O2 /Fd"Release\vc120.pdb" /Qvec-report1 /D "WIN32" /D "NDEBUG" /D "_LIB" /D "_UNICODE" /D "UNICODE" /Qstd=c++11 /Qipo /Zc:forScope /Gd /Oi /MD /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\MyApplication_library.pch"

The executable compiling options:

/MP /GS /GA /W3 /Gy /Zc:wchar_t /I"C:\Work\MyApplication\MyApplication_library" /Zi /O2 /Fd"Release\vc120.pdb" /Qvec-report1 /D "_UNICODE" /D "UNICODE" /Qstd=c++11 /Qipo /Zc:forScope /Gd /Oi /MT /Fa"Release\" /EHsc /nologo /Fo"Release\" /Fp"Release\MyApplication_test.pch"

linker options

/OUT:"C:\Work\MyApplication\Release\MyApplication_test.exe" /MANIFEST /NXCOMPAT /PDB:"C:\Work\MyApplication\Release\MyApplication _test.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "C:\Work\Speedsim30\Release\MyApplication_Controller.lib" /LTCG:STATUS /MACHINE:X86 /OPT:REF /SAFESEH /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"Release\MyApplication_test.exe.intermediate.manifest" /OPT:ICF /NOLOGO /TLBID:1

My personal computer has a powerful hardware configuration with Intel i7-4770K, 8 GB of DDR3-2133, and 2 SSDs in RAID0

thank you in advance

 

[Bernard]

How many thousands LOC does your executable have? How many header files does it include and how many translation units does it have?

For speeding up compilation you can enable multithreaded compilation.

[TimP]

The build may be slow due to interprocedural optimization.  There are options to split this and speed it up, short of disabling it, which would help deal with excessive memory consumption during ipo.

Extremely large functions with source unrolling also tend to compile slowly.
 

[Andrey_P_]

my

iliyapolak wrote:

How many thousands LOC does your executable have? How many header files does it include and how many translation units does it have?

For speeding up compilation you can enable multithreaded compilation.

:D

M executable consists of of ca 85 lines (yes just lines), which are calling methods for setting up and starting the computation. It includes just 3 headers, 1 of which is mine.

After transferring the .cpp with main to the library, i was able to build it as executable. BTW it showed 6 time computatation time improvement over debug.

[Bernard]

@Andrey P

Thanks for providing further explanation. I was under assumption that there is a lot of code to be compiled.

[Bernard]

Tim Prince wrote:

The build may be slow due to interprocedural optimization.  There are options to split this and speed it up, short of disabling it, which would help deal with excessive memory consumption during ipo.

Extremely large functions with source unrolling also tend to compile slowly.

 

It seems strange that program which contains only 85 LOC took hours to compile.

[Andrey_P_]

iliyapolak wrote:
It seems strange that program which contains only 85 LOC took hours to compile.

Actually it never did in original form. I canceled it after 20 hours and almost 1,5 GB memory consumption

[TimP]

iliyapolak wrote:

Quote:

Tim Prince wrote:

The build may be slow due to interprocedural optimization.  There are options to split this and speed it up, short of disabling it, which would help deal with excessive memory consumption during ipo.

Extremely large functions with source unrolling also tend to compile slowly.



 

It seems strange that program which contains only 85 LOC took hours to compile.

I guess the 85 lines is for the driver code; there must be a lot more in the library, and /Qipo is set for both.

[Andrey_P_ · Accepted solution]

Tim Prince wrote:


 

 

I guess the 85 lines is for the driver code; there must be a lot more in the library, and /Qipo is set for both.

As I wrote, it isn't that large. 9 classes each according to common practice in its own header + a header for enums that i use as symbolic constants. Beyond that I use std::vector quite widely and dedicated a class to make use of <random>. I also use a little bit <memory> and std::wstring.

But that doesn't matter anymore. Here is the right answer: the problem is in in /MT and /MD mismatch between the library and the executable - i must have misclicked, while setting up the release configuration. But it was somehow obscured by IPO. After I disable it the compiler/linker immedately showed appropriate error message. Correcting it allowed the executable to build.

[Bernard]

I am glad that you figured out how to solve the problem.