17

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.

Sergei Krivonos
  • 4,217
  • 3
  • 39
  • 54
Nathan W
  • 54,475
  • 27
  • 99
  • 146
  • I too have experienced this, my brand new Win7 quadcore machine at work takes at least 3 times longer to build my application than my 4yr old dualcore laptop at home. I took it as just being limitations with MinGW, but if you are experiencing it with VS, then obviously that's not the case. – cmannett85 Oct 12 '11 at 06:26
  • 1
    I found build times vasty improved by building on an SSD or a virtual ram drive (for which there is free software/drivers easily available) – Samuel Harmer Oct 12 '11 at 06:40
  • We've debated moving to SSDs, having read what Jeff Atwood has written about them. However, things like this on [SSD drive failure rates](http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html) made our Systems guys rather nervous! – Clare Macrae Oct 12 '11 at 07:06
  • I installed that very OCZ Vertex3 in my home system and it's blindingly fast. With a 6-core processor building from a spinning disk all cores run about 10%, but from the Vertex3 they're all consistently between 85% and 100%. (MinGW) (wrt failure rates; can't speak, been fine so far) – Samuel Harmer Oct 12 '11 at 07:16
  • 1
    My understanding is that it's dependent on the file IO speed, and "lots of small files" (compiling) is a lot slower on Windows. Not posting this as an answer because it's an anti-answer, but just letting you know that you probably can't expect equal performance. (I have heard that running Windows in a VM on Linux, effectively adding another layer between Windows and the storage hardware, can anecdotally be faster at compiling than raw windows, but I haven't done a fair comparison to know for sure.) – Ryan Pavlik Oct 12 '11 at 19:17
  • in the jom.zip see ibjom.bat which uses incredibuild – Sergei Krivonos Dec 04 '19 at 13:40

6 Answers6

17

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:

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.

Community
  • 1
  • 1
Clare Macrae
  • 3,670
  • 2
  • 31
  • 45
  • I'll check the network thing that might be causing some issues. – Nathan W Oct 12 '11 at 08:22
  • If it does turn out to be a network thing: we have about 12 devs, and require all build tools to be consistent, whilst still having local build tools. Our eventual solution was to have a master folder on the network, for all build tools, then have a weekly scheduled task that mirrors this out to each develop PC. This really helped. – Clare Macrae Oct 12 '11 at 08:36
3

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)

jalf
  • 243,077
  • 51
  • 345
  • 550
2

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/qt-creator@trolltech.com/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)

Paolo Brandoli
  • 4,681
  • 26
  • 38
  • Recent versions of MSVC can also compile multiple .cpp files in parallel within a project. – jalf Oct 12 '11 at 07:28
2

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.

David Feurle
  • 2,687
  • 22
  • 38
1

In Visual Studio did you go to:

Project -> Properties -> C++ and turned "Multiprocessor Compilation" to Yes ? That did the Trick for me turning on Multicore, which should speed it up actually quite much.

Stephan Dollberg
  • 32,985
  • 16
  • 81
  • 107
  • Does this add the /mp flag - only supported in 2008 (perhaps 2005?) and newer - apparently undocumented? – Ryan Pavlik Oct 12 '11 at 19:14
  • Here's [the VS2010 /MP documentation](http://msdn.microsoft.com/en-us/library/bb385193.aspx). See the 'Other Versions' link at the top of the page for the equivalent 2008 docs. – Clare Macrae Oct 12 '11 at 22:15
1

I think is best way by splitting your project into multi-projects each project is Static library project join them together by container project which is usually MainWindow class. Thus compiling duration will takes a while for first time then it will be short (depending on your modifications).

mbnoimi
  • 490
  • 4
  • 21