Fast Qt C++ compile on windows

Question

I have a large project that uses the Qt framework and am trying to find the fastest way to compile it on my Windows install.

On my linux machine at home I use 3 year old Linux Mint setup with a dual core (the machine is 3 years old not Linux Mint install), using: make -j2 both cores are used full(ish) and compiles the code relatively quick, around 10 minutes from clean build.

However on my work Windows PC which is 2.0 GHz Intel Core 2 Quad (XP) I can never seem to get the compiles to be as fast as my Linux box. The developer docs for the program recommend using Visual Studio C++ using the project file generated from cmake but that only seems to use one core and takes well over a hour to compile vs about 10 minutes (from clean build) on my Linux install.

I have tred using jom but even when using all the cores it still takes around an hour and half because it only seems to use small amounts of cpu on each core.

Doesn't make sense to me that my old Linux machine builds quick but the quad core just slumps along.

Answer 1

The following have helped the speed of our Windows C++ Qt builds, over the years:

1. Customised the settings on our anti-virus software, to exclude from scanning the locations of our Source code, object code, and all headers and libraries we are building against (Visual Studio, Qt etc). (There's a separate AV check that gets run overnight, to scan those excluded folders)
2. Ran a comparison of build speeds under various different AV packages. (This was several years ago, but as a result, we moved from McAfee to Sophos)
3. Made sure all files accessed during the build are on a local disk drive (we used to build against Qt on a network drive, but that killed the build performance)
4. Made sure that Visual Studio is configured to do multiple compile steps at once: This answer shows various ways of doing that.
5. Increased the amount of RAM: we're finding these days that 4 GB is the absolute minimum, for a sizable code base
6. Switched from static to dynamic linking, to massively shorten link times.
7. Moved to new versions of Visual Studio, as MS has improved performance: see this Visual Studio 2010 page, and search for 'Faster Compilation'

Our Windows builds are still slower than Linux ones, but I can't say that's a fair comparison, as our shared Linux build box is a much higher spec than developer PCs.

(As an aside, if you haven't seen them before, it's worth reading what Jeff Atwood has to say about good configurations for developer PCs: e.g. the Programmer's Bill of Rights)

Update: 25/10/2012

If you are on Visual Studio 2008, with DLL builds, I do not currently recommend moving to Visual Studio 2010: there is an issue with unnecessary re-linking of dependent projects that absolutely kills developer productivity, at least in a .sln with 20 or so .vcxproj files:

• Unnecessary relinks of dependent projects when building with Visual Studio 2010

There may be a solution to this - I'll update later, once I've tested it - see Unnecessary relinks of dependent projects when building with Visual Studio 2010 where CORCOR said:

If others have a similar problem:

Turning off the manifestation creation for the DLL projects and turning it on only for the application project helps!

With VS2008 this seemed to be no problem.

Answer 2

This might be a bit of a workaround, but we use Incredibuild, which distributes the build across multiple machines, which works really well. Cuts down our build times from 40 to 10 minutes. (we have 6 developer PCs hooked up to share the workload)

Answer 3

Visual Studio can compile several projects in parallel, but each single project is compiled sequentially. So if you compile a solution with 2 projects then two processes will be launched in parallel, but if you have just one project then just one process will start and it will compile your source sequentially.

If you use MingW, you can follow this thread: http://www.mail-archive.com/[email protected]/msg00156.html

There you will find the solution (install MSys and specify the parameter -j when you launch make in order to specify the number of parallel jobs).

An even easier solution is here: http://developer.qt.nokia.com/forums/viewthread/855/ (in QtCreator Tools->Options specify Jom as build tool instead of NMake)