How can I shorten my build/archive time in Xcode?

Question

My build/archive time in Xcode is longer then I would prefer. So I'm looking for way to build my project faster, and I know I'm on a not top end Mac. I'm thinking of upgrading to a new Mac. So my question is this:

Is Xcode mostly RAM or CPU heavy when building/archiving your project? That is, what should I look for in a new Mac so I can speed up my build/acrhive process?

Answer 1

Have you tried to find out how much time Xcode actually spends on which task when building your project? Usually developers only tend to make very small changes between project builds (e.g. just editing one or two files out of hundreds or thousands) and Xcode is usually very good at automatically skipping unnecessary steps (e.g. just compiling or copying the files that really have changed since your last build). In some cases though, Xcode cannot figure that out correctly and performs a lot more work than would really be necessary. Also your project-/build-setup may be unfortunate, forcing Xcode to perform much more work than would really be necessary. And in some cases it is possible to replace some build steps with other build steps that will execute a lot faster.

E.g. I have been able to reduce the build time of a large project from over 15 minutes down to under 5 minutes for a full, clean release build. And for another project I have been able to optimize the build process and reduce the rebuild time for developers from over 40 seconds to under 10 seconds when just editing a couple of source files.

As with all optimizations: You cannot optimize unless you really now where the problem is. So where exactly is Xcode losing its time? Is it building all the source files? And is it the huge amount of source files that takes so long or the compilation of only a few source files that are very large or include way too many headers? Is it the prefix header that takes too long to build? Is it build every time? Is it linking the object files together? Is it generating certain files dynamically? Is it building or Linking with dependent libraries or frameworks? Is it copying resource files? Is it processing resource files?

Answer 2

The first question is whether you're getting the most out of your current Mac. In particular, are you building in parallel as much as you possibly can? Open Activity Monitor during the build and hit Cmd-2. That will show all your cores separately. During the build, are they all running near 100% most of the time? If they are, then you're CPU bound, and more CPU is going to be helpful.

If they're idle a lot of the time, then there are two main possibilities: your build has dependencies (possibly incorrect) that prevent it from building in parallel, or you're bottlenecking somewhere else. Open the Memory tab in Activity Monitor. Are you swapping. If you are swapping, get more memory, period. There is no single thing you can do that will improve performance more than preventing swapping. Also, if you aren't on 10.9 yet, upgrade. 10.9 has several very clever improvements to memory management that make better use of the same resources.

Watch your build a little bit. Where does it take its time? A common place for it to bog-down in a very large project is in the link step (especially if you're doing a massive link of static libraries). Linking is often not CPU-constrained. Sometimes it's memory constrained, but often it's disk constrained. If so, as @bbarnhart notes, an SSD can make a big difference (a fusion drive makes a nice combination of SSD speed and HDD capacity).

Do you have a lot of ObjC++? ObjC++ is much slower to compile than ObjC or C++. If possible, reduce your use of ObjC++ and it'll speed up builds (and improve debugging, and reduce memory usage, and improve performance, and… I'm not a big fan of ObjC++, though it's gotten a lot better in recent clang versions).

But, in the most general of terms for what to buy first in most cases: always get as much memory as you can, then fast disks, then lots of CPU cores, then fast CPU cores. That is a typical order of bottleneck for modern compilers.