views:

1227

answers:

4

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!

+20  A: 

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.

Reed Copsey
+7  A: 

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!

Form
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!
Brad Parks
I never got LLVM working to compile for the iPhone. Is it really supported?
MrMage
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
Louis Gerbarg
here's a link to more info on the different compiler types supported by XCode 3.2: http://www.maccompanion.com/macc/archives/September2009/Columns/AccordingtoHoyle.htmI 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
Brad Parks
+1  A: 

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

Tetrad
+5  A: 

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.

Tim Keating
I don't think that would improve the checking dependencies portion of the build, just compiling.
wbyoung
True enough, but the question seems open to broad strategies to improve compilation times, so I think it's still relevant.
Tim Keating