Fast Qt C++ compile on windows

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)


I had the same problem. On our machines was a software running that tried to determine the compatibility with Windows 7. This software was logging every start of a software to a database and thereby slowed down the startup of new processes a bit. Since the compiler starts a new process for every file this significantly slowed down the whole compile run.


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)


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.