How to decrease build times / speed up compile time in Xcode?

Question

What strategies can be used in general to decrease build times for any Xcode project? I'm mostly interested in Xcode specific strategies.

I'm doing iPhone development using Xcode, and my project is slowly getting bigger and bigger. I find the compile / link phases are starting to take more time than I'd like.

Currently, I'm:

• Using Static Libraries to make it so most of my code doesn't need to be compiled everytime I clean and build my main project

• Have removed most resources from my application, and test with a hard coded file system path in the iPhone simulator whenever possible so my resources don't have to constantly be packaged as I make changes to them.

I've noticed that the "Checking Dependencies" phase seems to take longer than I'd like. Any tips to decrease that as well would be appreciated!

Solution 1

Often, the largest thing you can do is to control your inclusion of header files.

Including "extra" header files in source code dramatically slows down the compilation. This also tends to increase the time required for dependency checking.

Also, using forward declaration instead of having headers include other headers can dramatically reduce the number of dependencies, and help all of your timings.

Solution 2

I wrote an extensive blog post about how I improved the iOS development cycle at Spotify:

Shaving off 50% waiting time from the iOS Edit-Build-Test cycle

It boiled down to:

1) Stop generating dSYM bundles.

2) Avoid compiling with -O4 if using Clang.

Solution 3

Personally I switched compiler to LLVM-Clang for my Mac development projects and have seen a dramatic decrease in build times. There's also the LLVM-GCC compiler but I'm not sure this would help with build times, still that's something you can try too if LLVM-Clang does not work for iPhone app compilation.

I'm not 100% sure LLVM is supported for development on the iPhone but I think I remember reading in a news feed that it is. That's not an optimization you can implement in your code but it's worth the try!

Solution 4

If you're not using 8GB of RAM, upgrade now.

I just upgraded my macbook pro from 4GB to 8GB. My project build time went from 2:10 to 0:45. I was floored by the improvement. It also makes web browsing for research snappier and general Xcode performance when indexing, etc.

Solution 5

The number of threads Xcode will use to perform tasks defaults to the same number of cores your CPU has. For example, a Mac with an Intel Core i7 has two cores, so by default Xcode will use a maximum of two threads. Since compile times are often I/O-bound rather than CPU-bound, increasing the number of threads Xcode uses can provide a significant performance boost for compiles.

Try configuring Xcode to use 3, 4 or 8 threads and see which one provides the best performance for your use case.

You can set the number of processes Xcode uses from Terminal as follows:

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

Please see Xcode User Defaults for more information.

View more solutions

Comments

[Brad Parks]

thanks for suggesting this. I just did a few searches, and it sounds like it should work, and it is integrated into XCode (at least 3.2). Whether or not it's currently being used by my project is something I'll check into, as I guess older XCode project files may still default to the old "pure gcc" approach. thanks!

[MrMage]

I never got LLVM working to compile for the iPhone. Is it really supported?

[KeremV]

It is not supported for iPhone, but it works just fine for simulator builds, you just need to conditionalize the setting based on the SDK

[Brad Parks]

here's a link to more info on the different compiler types supported by XCode 3.2: maccompanion.com/macc/archives/September2009/Columns/… I don't have Snow Leopard yet (required for XCode 3.2?) but I think I'll have to consider getting it. A quote from the above url "if you can use Clang, you will see a nearly threefold performance improvement, in compile times, a major improvement over gcc. (I can hear old CodeWarrior users now sighing "Finally!")." but I don't know if it works with iPhone or not

[wbyoung]

I don't think that would improve the checking dependencies portion of the build, just compiling.

[surfer01]

True enough, but the question seems open to broad strategies to improve compilation times, so I think it's still relevant.

[Rob Napier]

My experience is that adding additional build servers can actually increase build times. In particular, Xcode defaults not to build on the master machine, using it only for coordination. So if the machine you're sitting at is the same speed or faster than your second box, speeds actually go down. Even with a couple of additional machines spread over a "normal" network (one not optimized for a build farm), I've found very mixed results.

[surfer01]

Interesting insight... "no default master" seems like a dumb choice. I have not used Xcode distributed builds with a codebase of any size, but I used to use distcc with a sizable linux project and adding even a crappy machine helped. Of course, it does nothing for link times, so if you have a project with a lot of linker work (a C++ project with lots of templates, e.g.), that won't really help you.

[Admin]

Would you know whether this strategy applies to recent XCode versions (e.g. 4.5) as I seem to notice a significant reduction in XCode memory usage?

[smileyborg]

This is a good recommendation, and is the default for new projects in Xcode now. Make sure to enable this for your Debug build configuration only, so that you don't have to remember to re-enable the setting when Archiving (using Release build configuration).

[Duck]

this option does not exist anymore.

[elliotrock]

thanks for this, your blog post has easy to follow steps.

[fons]

@elliotrock I'm glad this is still helpful (I would had assumed that XCode used better defaults by now).

[Hai Feng Kao]

I have 16GB, and it is still slow

[Mihailo Gazda]

Nah, this doesn't improve anything, tested it.

[Fattie]

even years later, your DWARF TIP is mindboggling, @fons dude. it looks like you moved on from Spotify, and it's still mindboggling heh :)

[Joaquim Paz Carvalho]

It does work, quite dramatically! Both on a 2009 MacBook Pro as well as on a 2014 11" Air. Just try it. If you did not notice anything you probably did not change the path correctly. Why? Because writing to a hard disk, or even a SSD, takes time. Xcode writes quite quite a lot when compiling. It also saves battery. The only downside is that the RAM disk gets full after a few hours of work. Then I have to exit Xcode, delete the files, empty the trash and start again. A bigger RAM disk would fix this but my computer has only 8Gb

[Pavel P]

@fons What about static libs? It doesn't make sense for them to have dSYM in release builds. In my case most of the code is in static libs, and it kind of makes sense to have dSYM only when building final binary (which links in all these static libs from my project).

[Pavel P]

googling gave this answer: "except that a dSYM file is not needed and will not be created for static library or object file products" - so yes, this simply makes no sense to have dSYMs for static libs.

[Yaro]

shouldn't we copy the project files to RAM disk to have maximum effect?

[Naresh]

I have 32GB, and it is still slow

[Dani]

@MihailoGazda how much RAM is Xcode using in Activity Monitor?

[firetrap]

2,4Ghz i9 with 64GB and it is still slow