Back to General and Gameplay Programming

Speed up Compile Times

General and Gameplay Programming Programming

Started by RealMarkP May 14, 2008 06:22 PM

31 comments, last by Rydinare 15 years, 11 months ago

116

May 15, 2008 09:57 AM

Quote:I'll see about getting MSVC 2008 form my school. Does it matter which version you get (Express, or Professional, or anything in between?)

No, even the express version can use the /MP switch, but you always hav to add it yourself (it's off by default).

Quote:Its a lot of work IMO, I was going to leave it for headers that I no longer need to work on. Which might be a long ways away..

Really consider using precompiled headers, the impact will be huge, trust us.
- make a general header, say you call it stdafx.h for example, and #include all API and libraries here
- make a translation unit dedicated for the compilation of the general header. Call it stdafx.cpp and add only one line in it : #include "stdafx.h"
- in your general project properties, select "Use precompiled header" in the "precompiled headers" tab
- right click on stdafx.cpp, properties, and select "Create precompiled header" in the "precompiled headers" tab
- in each .cpp file : remove all API and libraries includes, and #include "stdafx.h" at the top of the file

[Edited by - rolkA on May 15, 2008 10:57:50 AM]

English is not my native language.Sam.

hydroo

295

May 15, 2008 10:18 AM

- reducing dependencies
- using forward declaration instead of inclusion of headers

btw I hate pImpl. It just makes me angry everytime I forget to add changes twice.
I only use it to hide details in classes which are open to the public.

Krazy (part of the KDE project) checks if the QT-headers you include are even needed. Would be nice to have something like that in general.

Quote:Original post by emeyex
separate code into libraries so you only have to compile the libs you change

Don't do extra libs until you really want to make something plug-able or it is really something generic, which you will use in other projects.
It just makes things more complex.

Rattenhirn

3,115

May 15, 2008 10:20 AM

Quote:Original post by RealMarkP
Quote:Original post by emeyex
why not use pre-compiled headers?

Its a lot of work IMO, I was going to leave it for headers that I no longer need to work on. Which might be a long ways away.

Just precompile the standard c and c++ headers.

Those won't change a lot, obviously, but the compile time speed up can be huge.
Especially when you use a lot STL stuff.

Rydinare

487

May 15, 2008 12:15 PM

Only pre-compile headers that aren't likely to be changed by you. Anything more and the burden becomes more than the benefit.

That being said, I don't always find pre-compiled headers to be a huge win (They do help when used carefully). If you have a lot of small, modular projects, the benefits of pre-compiled headers reduces significantly, since there's no way (that I know of) to tell multiple projects to use a single precompiled header.

Sneftel

1,788

May 15, 2008 12:30 PM

Quote:Original post by Rydinare
Only pre-compile headers that aren't likely to be changed by you. Anything more and the burden becomes more than the benefit.

That being said, I don't always find pre-compiled headers to be a huge win (They do help when used carefully). If you have a lot of small, modular projects, the benefits of pre-compiled headers reduces significantly, since there's no way (that I know of) to tell multiple projects to use a single precompiled header.

If you have multiple projects, then you include all the dependencies' headers in your StdAfx.h file. A lot of small, modular projects is the ideal case for precompiled headers.

aclysma

180

May 15, 2008 12:51 PM

Not to derail but.. /MP cannot be used at the same time as /Gm (enable incremental build).

In which cases is one better than the other? As for release mode, Gm was already turned off for me, but I don't notice a difference in debug mode.. I post numbers when I try them both.

EDIT: Dropped my 3.5 min compile time to 2.5 min - so MP is an improvement but still not sure if it is faster than incremental builds).

[Edited by - aclysma on May 15, 2008 1:51:21 PM]

Rydinare

487

May 15, 2008 01:38 PM

Quote:Original post by Sneftel
Quote:Original post by Rydinare
Only pre-compile headers that aren't likely to be changed by you. Anything more and the burden becomes more than the benefit.

That being said, I don't always find pre-compiled headers to be a huge win (They do help when used carefully). If you have a lot of small, modular projects, the benefits of pre-compiled headers reduces significantly, since there's no way (that I know of) to tell multiple projects to use a single precompiled header.

If you have multiple projects, then you include all the dependencies' headers in your StdAfx.h file. A lot of small, modular projects is the ideal case for precompiled headers.

Hmmm. Do you want to explain further? Here's my problem with precompiled headers. Let's say I make a change to X's header and it's common to projects A, B and C. I don't want to have to rebuild the entirity of A, B and C if only a single file from each of those was using that dependency. That's where I've found precompiled headers to have issues, in cases where they force everything to rebuild.

Mind you, some of my comments are tailored towards a large project I work on (2 million LOC).

Driv3MeFar

1,080

May 15, 2008 01:52 PM

Take a look at this article.

We use something similar to the single compilation unit idea at work, and it cut about 30 minutes off our build times.

Rydinare

487

May 15, 2008 02:20 PM

Quote:Original post by Driv3MeFar
Take a look at this article.

We use something similar to the single compilation unit idea at work, and it cut about 30 minutes off our build times.

Hmmm, but then that means every change = full rebuild. I like the premise and I could see it reducing our build time by 75% or more, but I don't think it's practical for large projects, due to the lack of modularity.

Sneftel

1,788

May 15, 2008 02:44 PM

Quote:Original post by Rydinare
Hmmm. Do you want to explain further? Here's my problem with precompiled headers. Let's say I make a change to X's header and it's common to projects A, B and C. I don't want to have to rebuild the entirity of A, B and C if only a single file from each of those was using that dependency. That's where I've found precompiled headers to have issues, in cases where they force everything to rebuild.

If X is actually common to A, B, and C -- that is, it's needed in most of A's files, most of B's files, and most of C's files -- then there's no way around a large rebuild. That's the nature of changing headers that a lot of projects include. In a situation where things are widely separated, though, an individual non-system header will probably not show up in more than a few of your many, many small projects, so the effects will be limited. Compare to HugeApplicationB which depends on HugeLibraryA, where a change to HugeLibraryA's ToasterControl.h, included in HugeApplicationB's stdafx.h, forces an entire rebuild of HugeApplicationB (even the non-toaster-related parts).

Speed up Compile Times

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Speed up Compile Times

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines