1

I have a console application written in C/C++. Usually it takes, 5-10 minutes to get compiled on non-windows platforms even though optimization flag is set to -o3. But it takes approximate 1-2 hours to get compiled on Windows platform when optimization flag is set to Full Optimization (/Ox) and Inline Function expansion is set to Any Suitable (/Ob2) in visual studio. This happens in release/debug mode both.

I understand compiler is trying to optimize the code hence it is bound to take more time but isn't it too much time compare to time taken by other compilers(mainly g++) on non-windows platforms.

So far I tried..

Removed unnecessary headers from source and header file, introduced forward declarations wherever possible but no respite.

I analyzed the all header files. Templates are used hardly in 2-3 header files out of ~50 header files in project. These headers are also not widely included in the source files.

I've two observations from this behaviour -

  1. There is nothing terribly wrong in the source code otherwise compilers on non-windows platforms would not be able to finish so quick.

  2. Seems VS compiler genuinely taking more time(1-2 hours) which other compilers are able to do in(10 minutes) but VS compiler can't be that bad. Therefore, I must be missing to change some configuration (apart from optimization).

Does anyone has idea how to find out what is going wrong here ? May be starting point will be to identify compilation time taken by each file. How do I find compilation time of each file ?

Could there be possibility if I can still improve/try something ?

Here are additional details about hardware, source code etc as requested in some of comments

RAM - 8.0 GB RAM

OS - Windows 7 64 bit

Processor - Intel Core i5 2.6 GHz

Visual Studio - 2013 Ultimate

Note - If I disable optimization (set /Od and /Ob0 flags in VS) then program compiles in less than 5 minutes on the same machine.

Source files - approx 55, header and source files each and 80KLOC code.

irsis
  • 952
  • 1
  • 13
  • 33
  • Please specify the following: approximate number of files; relevant hardware specs for the windows machine (processor(s), RAM) – utnapistim Mar 10 '15 at 12:29
  • Hmm, this is unusual. Nevertheless, not something you should ever be waiting for. Building the Release version is a the job of a build server. It just slaves away at it, nobody waits for it. – Hans Passant Mar 10 '15 at 12:43
  • Is it C or is it C++ or is it a mixture of both? One possible problem is that other compilers compile C as C whereas MSVC might be compiling it as C++. C++ compilers are notorious for taking forever to compile things. – JeremyP Mar 10 '15 at 13:34
  • 3
    Related [The `/mp` build option](http://stackoverflow.com/q/1422601/332733) – Mgetz Mar 10 '15 at 13:42
  • @JeremyP It is mix of C and C++. – irsis Mar 10 '15 at 13:42
  • @Rahul you might want to try compiling the C explicitly as C with the C compiler then. – JeremyP Mar 10 '15 at 13:53
  • @JeremyP the MS compiler is smart enough to know C from C++, there are other issues here that are probably not related to C++ that are causing a bigger slowdown here. – Mgetz Mar 10 '15 at 13:55
  • Related: [How do YOU reduce compile time, and linking time for Visual C++ projects? (native c++)](http://stackoverflow.com/questions/364240/how-do-you-reduce-compile-time-and-linking-time-for-visual-c-projects-nativ/364263#364263) – crashmstr Mar 10 '15 at 14:03
  • @Mgetz I think the issues almost certainly are related to C++ and the VC++ compiler. Or perhaps they are related to the C compiler which is way behind the times compared to other C compilers. – JeremyP Mar 10 '15 at 14:05
  • 2
    One alternative approach for measuring build time of each file: remove all object files - build a program. Measure difference between time of last change and time of creation for each object file (can be done with some scripting language). When you find culprit files it sometimes helps to make `#pragma optimize ("g", off)` on whole file or certain functions if optimization is unnecessary. – Predelnik Mar 10 '15 at 14:06
  • Please add version specs of your Visual Studio and the *full* compiler flags (Goto: Properties - c/c++ - Command Line). Do you have the `/analyze` switch on ? – Martin Ba Mar 10 '15 at 14:12
  • There is no such thing as "a mix of C and C++" among files processed by a single compiler. Either you are using a C compiler, or you are using a C++ compiler. Which is it? – Lightness Races in Orbit Mar 10 '15 at 14:30
  • Could you incorporate new information into the narrative of your post, rather than making it a chronological blog of events? Right now it looks more like a chat room conversation: perhaps it would be better suited there? Thanks. – Lightness Races in Orbit Mar 10 '15 at 14:30
  • @LightnessRacesinOrbit sure, I'll add a consolidated answer. – irsis Mar 10 '15 at 15:18
  • @Rahul: No, I mean, the _question_ should be consolidated. – Lightness Races in Orbit Mar 10 '15 at 15:27
  • @LightnessRacesinOrbit I'll do it :) – irsis Mar 10 '15 at 15:35

2 Answers2

0

Does anyone has idea where to start to find out what is going wrong here ?

Not without more details.

Could there be possibility if I can still improve/try something ?

Yes. In particular, consider:

  • removing any templated code from header files (both included and defined in the .h file), and accessing that code through pimpl (because templates are reevaluated on each pass).

  • optimizing your usage of precompiled headers

  • splitting your console application into separate modules (so your build system will only update the dirty binaries on build)

utnapistim
  • 26,809
  • 3
  • 46
  • 82
  • May I know what more details are required ? I'll try to provide as much possible. – irsis Mar 10 '15 at 12:37
  • It is possible that most of this delay is caused by a single dependency (for example, a large templated class that is included virtually everywhere), but if that is the case, it is not apparent from the information you provided; it is also possible that an external factor is limiting access to the source code (like some of the files being accessed through a network share); also, see my comment (number of files, approximate size of files, etc). – utnapistim Mar 10 '15 at 12:43
  • I mentioned this information in Edit 2. None of files are accessed through network share. The libraries it is dependent upon are present on the local machine. Had this been the case then it would have taken same time with optimization flag turned off. – irsis Mar 10 '15 at 12:52
0

Based on suggestions received in comments, I started by finding out compilation time taken by each file:

  1. Clean project to ensure all *.obj files are removed
  2. Build the project again
  3. Noticed the time stamp for each file and I found a file which was taking almost two hours to compile.

When I open the source file I see something terribly wrong in the code in contrast to my observation. It is a huge monster file of 27KLOC (Opps!, of course I didn't write this file). There are 739 instances of a class created dynamically and assigned to an array. Each instance in turn dynamically creates some of its members as well. In shorts thousands of objects are being created in this file.

To ensure that this file is the culprit and VS studio is taking way too much optimizing this file. I disabled the optimization in this file as proposed by @Predelnik in comments. Voilà! program compiles within couple of minutes now. This source code needs a serious re-factoring.

If someone is facing such problems, I would go as following -

  1. Enable Build-And-Run option and /MP flag. As discussed Here. If there is some problem with the code the parallel projects and file compilations would not help.

  2. Find out if any source file is the culprit as above. I believe the link I found Here is a way to calculate the build time not compile time of each file.

irsis
  • 952
  • 1
  • 13
  • 33