# C++ 40 seconds to compile a .cpp file - is it totally normal?

## Recommended Posts

10 hours ago, ChaosEngine said:

That said, for a 320 line file, it should be fine.

320 lines of code in the main C++ files, and however many thousands lines of code are directly and indirectly included.  The code in the actual C++ file is rarely the main culprit when it comes to slow compile speeds.

##### Share on other sites
On 10/10/2019 at 7:30 PM, Acosix said:

8 RAM is a lot. So is 3.2 GHz

On 10/11/2019 at 8:43 AM, ChaosEngine said:

3.2GHz i5 is fine, but not excessive. 8Gb is definitely on the low side.

Thank a lot, Acosix and ChaosEngine.  It is very useful advise.

On 10/11/2019 at 7:53 PM, a light breeze said:

.... however many thousands lines of code are directly and indirectly included.  The code in the actual C++ file is rarely the main culprit when it comes to slow compile speeds.

Yes, absolutely true.   I found no automatic tool that count all lines indirectly included though. >.<

##### Share on other sites
3 hours ago, hyyou said:

Thank a lot, Acosix and ChaosEngine.  It is very useful advise.

Yes, absolutely true.   I found no automatic tool that count all lines indirectly included though. >.<

gcc and clang support the -E option to preprocess a source file without compiling.  By checking the output, I can easily see that (for example) #include <iostream> by itself yields 28138 lines of code on my computer!

##### Share on other sites
19 hours ago, a light breeze said:

#include <iostream> by itself yields 28138 lines of code on my computer!

That is a stunning figure.   I will be more careful about #include.

Thanks, a light breeze

##### Share on other sites

Did OP tried to use a pre-compiled header?

##### Share on other sites
On 10/10/2019 at 12:36 PM, Bregma said:

My next guess is that you're using template-heavy code.  It's going to increase compilation times.  Header only libraries and template-heavy code go hand-in-hand, and both are compile-time performance killers

That is a very good candidate. Are you using any std related stuff?
Instead of workarounds try to locate the real problem. if your cpp file is not that big, try removing parts of it (code/include/both) and see what happens. 40 sec is way too much for a single file. It should be enough to full-rebuild a half million line code base, without unity build

##### Share on other sites

18 hours ago, Alessio1989 said:

Did OP tried to use a pre-compiled header?

Thank.  OP (me) uses it.

1 hour ago, bmarci said:
On 10/10/2019 at 5:36 PM, Bregma said:

My next guess is that you're using template-heavy code.  It's going to increase compilation times.  Header only libraries and template-heavy code go hand-in-hand, and both are compile-time performance killers

That is a very good candidate. Are you using any std related stuff?﻿

Thank.

Yes, I do #include <sstream> for printing log.  It is included as the top header.   I don't use Boost.

Most other libraries I used are created by custom, e.g. I use my own MyArray<T> instead of std::vector<T>, and custom MyPtr<T> (probably direct+indirect ~400 lines) instead of just T*.

I don't know how to measure/profile compile-time penalty I get from template.  I am using Visual Studio.

##### Share on other sites

Probably made the mistake of #including windows.h...

One of the tricks I use for non-template external libraries / functions that have 'expensive' includes, is to wrap them in your own .h / .cpp file. So you only include your own .h to use the functions rather than the third party. Yours can be clean and fast compiling, even if the external is rubbish.

E.g.

//my_windows_wrapper.h
#pragma once

#ifndef QUICK_BUILD
#include <windows.h>
#endif

class WinWrapper
{
public:
#ifdef QUICK_BUILD
void some_windows_func();
#else
// will get optimized out
void some_windows_func()
{
// call windows
some_dodgy_windows_func()
}
#endif
};

//my_windows_wrapper.cpp
#include "my_windows_wrapper.h"

#ifdef QUICK_BUILD
#include <windows.h>

void WinWrapper::some_windows_func()
{
// call windows
some_dodgy_windows_func()
}
#endif

Then for final release you can change the QUICK_BUILD define and it will link directly to the third party code. There might be an even better way of doing this.

Optimizing compile / link times can be really important in big projects to reduce iteration time, and there's no reason why you can't do it at zero cost for final release builds.

##### Share on other sites
28 minutes ago, lawnjelly said:

One of the tricks I use for non-template external﻿ libraries / functions that have 'expensive' includes﻿

Why would you parameterize that with a macro, when you can just isolate that implementation detail into its own .CPP?

// service.h
#pragma once

class Service {
public:
void default_operation(void);
};

// common/service.cpp
#include "../service.h"

void Service::default_operation() {
ServicePayload basic( /* ... */ );
send_operation(basic);
}

// windows/service.cpp
#include "../service.h"
#include <windows.h>

// ...
}

// linux/service.cpp
#include "../service.h"
#include <iostd.h>

// ...
}

... and then always link against common/*.o, and link against only windows/*.o or linux/*.o depending on which EXE you're building.

##### Share on other sites
8 hours ago, lawnjelly said:

Probably made the mistake of #including windows.h...

7 hours ago, Wyrframe said:

Why would you parameterize that with a macro, when you can just isolate that implementation detail into its own .CPP?

Thank, lawnjelly and Wyrframe.    I already separated <window.h> to .cpp.

My problematic cpp file does not #include <window.h> neither directly nor indirectly (I just check it), but your advises (and JoeJ's) make me realize that I really should enable "C/C++>Advanced>Show Includes" compiler log.  Thanks.

## Create an account

Register a new account

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 17
• 16
• 13
• 20