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!

Ehrenburg

Answer 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.

Exclusive

Answer 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.

Vo

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

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

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

@Vo 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). – Midst

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. – Midst

Answer 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!

Wilkinson

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! – Ehrenburg

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

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 – Ohmage

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 – Ehrenburg

Answer 4

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.

Oystercatcher

this option does not exist anymore. – Pep

Answer 5

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.

Dysart

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? – Goddamn

I have 16GB, and it is still slow – Detradetract

I have 32GB, and it is still slow – Piscary

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

Answer 6

Easy answer: add another machine running Xcode on your local network. Xcode incorporates distcc to do distributed compiles. It can even use Bonjour to find other build hosts, which simplifies the process of configuring this greatly. For large builds, distributing can get you a speed increase that is nearly linearly proportional to the number of build machines (2 machines takes half the time, three takes a third and so on).

To see how to set this up, you can consult this development doc. It also features other useful build time improvement strategies, such as using precompiled headers and predictive builds.

Edit: Sadly, it appears Apple has removed this feature as of Xcode 4.3: http://lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

Xcode 5 has a server version which can do CI, but I doubt this will confer any benefit for ad hoc developer builds. However, there are some unannounced features that should dramatically speed up build times.

Lavadalavage

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

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

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. – Cordula

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. – Lavadalavage

Answer 7

One huge tip to halve compile times (for iOS projects at least) is to set Build Settings / Architectures / Build Active Architecture Only to YES.

What this does (especially with the advent of 64-bit iPads/64-bit compiler) is to not build the binary for the architectures you're not currently using.

Make sure you remember to re-enable this setting on submission to the app store, or your binary will not validate.

Fricandeau

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). – Coincidental

Answer 8

I used a script to make use of a RAM drive, together with some "forward declarations" optimizations my project clean build time went from 53 seconds to 20 seconds.

I was tempted to get the Gui on the AppStore, but opted rather to go for command line. I put the script as part of git repository.

To see the build times, enter this in a terminal: "defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES"

Restart Xcode to notice the build times in the toolbar. (this is my non clean build time using objective-c)

Adjust the script to your liking. - Note the script clears the derived data folder.

#!/bin/sh

#2 GIG RAM
GIGA_BYTES=$((2*1024*1024*1024))

# a sector is 512 bytes
NUMSECTORS=$((${GIGA_BYTES}/512))

#ram disk
mydev=`hdiutil attach -nomount ram://$NUMSECTORS`
newfs_hfs $mydev

# make mount point
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData

# ******************************************* 
# ** WARNING - MOUNT POINT WILL BE DELETED ** 
# *******************************************
rm -rf ${MOUNT_POINT}
mkdir -p ${MOUNT_POINT}

# mount
mount -t hfs $mydev ${MOUNT_POINT}
echo unmount $(MOUNT_POINT)

To see the effect and to control the RAM Drive:

mount                       - see mount points
umount mount_point          - unmount point
diskutil list               - see disks
diskutil eject /dev/diskX   - eject the disk
df -ahl                     - see free space

NOTE: I essentially use the hdiutil provided by macOs. I tried switching the -kernel option (no swapping to disk) on but failed on my machine, saying it is not implemented.

Maybe the new OS coming soon we will see even more improvements as the new file system copy feature is really fast, and possibly makes this script redundant.

Grimmett

Answer 9

You mentioned using static libs for your most-often used files to prevent compilation. You can accomplish something similar by putting headers to your code that it's frequently used but not in your static libs in the precompiled header. At least they'll only be compiled once.

Care must be taken to avoid issues if you have multiple compilation types across your project (e.g. Obj-C, Obj-C++, C++).

Recrudescence

Answer 10

Hey there, I would recommend you to optimize your project's physical structure. There's some good reading about this ( at least in the C++ world ) , but I do objective-C and the same principles often apply.

Here's a great article about project's physical structure optimization, which tends to improve compile times Games From Within: Physical Structure Part 1

Good luck :)

Nims

Answer 11

one word: TmpDisk

1. Use TmpDisk to Create a 1.5Gb RAM disk
2. Change Xcode > Preferences > Location > Derived Data to /Volumes/1.5Gb/xcode data
3. Enjoy the speed!

Roller

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

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 – Roller

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

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

Answer 12

Quick Note Regarding 'Throw more hardware at it' approach..

SUMMARY: I experienced a SMALL speed increase from making a SIGNIFICANT hardware upgrade

Test: Build/Run the exact same project on cloned macbooks (where the only difference should be their hardware)

Old Macbook Air (1.86GHZ Core 2 Duo ONLY 2GB RAM) vs Brand New Macbook Pro (2.3GHZ Core i7 8GB RAM)

BUILDING ON IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro ~1:00

=> 0 to 0:15 of speed increase

BUILDING ON IPHONE 4S
Macbook Pro ~0:35
Macbook Air ~0:50

=> ~15 seconds of speed increase

**Partially tested: There DOES apear to a significant difference between build times for the SIMULATOR between the 2 machines

In my continued experience.. you WILL get a significant increase when making big changes in PHONE hardware (i.e. build time on a 3GS vs iphone 5 (or 4 for that matter)).. at least in my experience, the limiting factor was the phone hardware (not the computer hardware).

SO.. to get the fastest build time..
option1) write code and run in the simulater on a fast computer OR
option 2) build on the device with the lastest iphone

Contractor

Answer 13

If your whole project gets rebuilt every time you hit run, that's probably the bug in XCode 7.0 <= 8.1 giving you a hard time.

Creating the user defined build setting HEADERMAP_USES_VFS to YES cut the macbook compile time from 75 seconds each time, to 25 seconds. See Xcode 8 does full project rebuild for more info.

Trichiasis

Answer 14

I switched to Hackintosh with a 5960x CPU, overclocked to 4.4GHz only to bring down Xcode compile time. That's 8 cores and 16 threads. Total cost $3000 for a computer that crushes all macs. However I've spent at least 10 days getting it set up, first with Yosemite, the. I had six months downtime when I couldn't update macOS while Xcode required a newer os. I just got it running sierra and life is good again.

My 2,8 GHz i7 double core 16 GB RAM MacBook Pro compiles my project in 75 seconds, the Hackintosh in 20 seconds. (Swift, dlib, opencv c++ in the project)

However the biggest problem is Xcode doesn't seem to use multiple threads when compiling swift. This is the bottleneck, I hope they will fix it soon.

Trichiasis