How to decrease build times / speed up compile tim

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!

Answer 1

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!

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.

Answer 3

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 :)

Answer 4

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

Answer 5

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.

Answer 6

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++).