Jump to content
  • Advertisement
Sign in to follow this  
Woodchuck

Compilation time.

This topic is 3981 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, We've got a problem here : the compilation time. We've got something like 70000 lines of advanced C++ code (lots of template, of macros, of classes etc.). On a core 2 duo 6600, 2Go of RAM, it take near 30 minutes of compilations with visual express edition (note that this ide use the 2 cores of the core 2). Do you think it's normal ? If not, what can drastically improuved the compilation performance ? What kind of practices are to be avoided ? Notes : 0) we are using precompiled header. 1) we have /Zm problems, we must compile with /Zm1024. 2) we have /bigobj problems. 3) we have the impression that the macros are the problems. what are you thinking about that? 4) we compile with full optimizations (but not the 'whole program optimization') Thank you.

Share this post


Link to post
Share on other sites
Advertisement
While I think VC++ 2005 is overall a great IDE / compiler, a few things in it are a little dodgy. Build times are one of these things. Sometimes I have project that builds from start to finish in no time at all. Then I make a number of changes in a few files and suddenly building the project gets DOG SLOW, even though none of the changes made should reasonably have any significant effect on the time it takes to build the project.
Maybe I'm missing one of the service packs or something.

Share this post


Link to post
Share on other sites
Quote:
Original post by mastersmith
instead of rebuilding the whole project why don't you just link the previously changed files?


Ooops, I forgot to mention that we've got something like 8 projects in the solution. We often recompile 6-7 projects.
The whole compilation take 30 minutes.

Quote:
Original post by Red Ant
While I think VC++ 2005 is overall a great IDE / compiler, a few things in it are a little dodgy. Build times are one of these things. Sometimes I have project that builds from start to finish in no time at all. Then I make a number of changes in a few files and suddenly building the project gets DOG SLOW, even though none of the changes made should reasonably have any significant effect on the time it takes to build the project.
Maybe I'm missing one of the service packs or something.


That's interresting.


Thanks for reply.

Share this post


Link to post
Share on other sites
all you should have to do is compile the 8 projects once, then just compile the on file you changed and be able to link it into the project. btw why do you have eight projects? hl2 has one of the largest code bases I have seen and it consists of 2 projects

Share this post


Link to post
Share on other sites
We currently have 9 projects (seperate modules for core/logic/rendering/high-level game/editor/server and a few more).

Some modules (like game and server use 'low-level' projects like core &
logic (to share code).

I would estimate we have 200-300k lines of code and a rebuild of release
and debug using incredibuild (on max 50ghz) takes around 20 minutes.
(edit: Just checked it - 450k loc - without sdk's)

>Then I make a number of changes in a few files and suddenly building
>the project gets DOG SLOW
That might happen if you change a header which is included in many places.

Also be sure to use forward declarations, and to avoid including headers
in headers (if possible). Better to fwd declare and include in the .cpp.

Also take a look at www.xoreax.com for incredibuild (commercial, but
increases productivity drastically, it's definitely worthwhile )

Regards

[Edited by - Kitt3n on July 27, 2007 8:40:09 AM]

Share this post


Link to post
Share on other sites
70,000 lines of code is not going to be quick, by any means. However, I'm sure that somethings can be done. First off, do you really need to compile debug versions with full optimizations on? That seems pointless to me. Next, try googling for the "Physical structure of code". I found some articles a while back (lost them, since then) that nicely explained what can cause these long compile times. A bit of clean up (mostly of often-used header files) and I noticeably reduced my compile time. Small things like using forward declarations instead of #include-ing it's header whenever possible makes it go a bit faster.

Share this post


Link to post
Share on other sites
The project I'm currently on has well in excess of 500,000 lines of code (possible 750,000), mostly managed C++ but with some C# and plain C++ and a full rebuild takes around eight minutes. That's on a 3GHz Dual Core P4 with 1GB of RAM.

I think that you're not using precompiled headers properly. Could you post the contents of yuor precompiled header file ("stdafx.h" normally), the precompiled header compiler options for a typical source file and the precompiled header compiler options for the precompiled header source file ("stdafx.cpp" normally).

Skizz

Share this post


Link to post
Share on other sites
I don't think macros are the problem, they're generally not an issue for performance.

/Zm issues sounds like you have too much stuff in your precompiled header (or just way too many headers in general). When you say heavy use of templates, how heavy? Having a lot of templates in your headers could bloat the pch a lot. Having a 500MB pch (as you currently have) is going to affect speed significantly.

/bigobj sounds like way too many templates getting expanded into one module, try breaking the code up into smaller sections.

70000 lines should not take 30 minutes to build. I can build about 120,000 lines in under a minute on an A64 4400+ at work (in 2 dependent projects, so no multi-core compiling too).

Something I've noticed that has a big impact on compile times in MSVC is templates. The more templates you use (or even include) the slower your compiles and the bigger your target exe. MSVC doesn't seem to have particularly good template handling. :p

Share this post


Link to post
Share on other sites
Several man days of refactoring to reduce compilation times are affordable, so you can start by figuring out why typical changes require compiling over 80% of the project, whether you can split the existing projects and source files and avoid recompiling unchanged parts, how you can contain dependencies with code changes. There are many techniques, like the "PIMPL" pattern, that can help you restructure your code.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!