In between midnight summer nights and dark winter days

Quick tip: Speeding up Xcode compilations Thu, Mar 03 2011 12:06

I just saw some benchmarks over at Phoronix comparing Snow Leopard and the developer preview of Lion. One of the differences is that the Lion kernel boots in 64-bit mode by default. One of their benchmarks measures compile time, and the results indicate that a 64-bit kernel might boost the speed of compiling code. Noticing that my MacBook Pro was running the 32-bit version of the Snow Leopard kernel, I decided to run some informal tests myself.

My test-case was a full build of the FolderGlance code base. I timed the build with my iPhone, so the results are not completely accurate. However, barring any measurement inaccuracies, the results were quite good:

Time57.3 s50.2 s

Pretty good for simply switching to the 64-bit kernel! In case you are wondering: Switching to the 64-bit kernel can be done by either holding down the 6 and 4 keys while your Mac is booting, or you can execute the following command from Terminal to make the change persistent:

sudo systemsetup -setkernelbootarchitecture x86_64

Read more here:

This got me wondering if I could speed up compiles further using additonal processes. Xcode defaults to using the same number of sub-processes as the number of cores your Mac has. My MacBook is of the Intel Core i7 variety, with two cores, 8 gigs of RAM and an SSD disk. I figured I might try to up the ante, since compiles are often I/O-bound rather than CPU-bound, although I was skeptical since my Mac has an SSD disk.

I configured Xcode to use 3, 4 and 8 subprocesses, instead of the default 2. You can set the number of processes Xcode uses from Terminal as follows:

defaults write PBXNumberOfParallelBuildSubtasks 4

These are the results I got (all on the 64-bit kernel):

Time57.3 s44.5 s43.3 s47.0 s

So, for now I'll up the number of subprocesses Xcode uses to 4, since that seems to provide the best performance for this particular use case. The best number will also vary depending on the disk you use, how much memory you have available and the kind of code you are compiling.

Previous: FolderGlance 3.0 Next: FolderGlance 3.0.1 supports Lion

About me
My name is Daniel Stødle. I live in Tromsø, Norway, at 69.66° North. By day, I work as a researcher at the Northern Research Institute in Norway; by night, I run my company SCSC. I do most of my development on and for Mac OS X. My research is geared towards interaction with and visualization of geospatial data. Read more on my personal page.


Contact me

Recent posts

Jul 28: Running iTunes in a debugger (gdb)
Jul 25: The /Volumes/MobileBackups directory
Jul 20: FolderGlance 3.0.1 supports Lion
Mar 03: Quick tip: Speeding up Xcode compilations
Mar 02: FolderGlance 3.0
Jan 07: Making Universal Back Button work on 10.6.5 and later

Sep 03: Creating pthreads in C++ using pointers to member functions
May 31: Quickly open URLs in Terminal
May 31: Snow Leopard and automatically submitted Crash Reports
May 27: Universal Back Button released for Mac OS X
May 22: The 22 Megapixel Laptop
Feb 09: FolderGlance on MacUpdate Promo

Sep 28: FolderGlance 2.5.3 is out
Sep 21: FolderGlance 2.5.1 adds features and fixes bugs
Sep 16: FolderGlance 2.5 released!
Sep 10: Intriguing: Snow Leopard ships with the iPhone's multi-touch API built-in
Sep 03: FolderGlance and Snow Leopard
Mar 15: Fixing Keynote '08 and '09 to work with the Scripting Bridge
Feb 26: A website in an image
Feb 09: Display wall multi-touch

Feb 19: Spaces.. Spaces.. Spaces.. retires
Feb 08: How-to: Reverse engineering the Dock to fix Spaces
Jan 25: Interacting with wall-sized displays

Dec 20: Interesting Finder bug
Dec 06: Developing applications for the iPod touch (and the iPhone)
Nov 15: Spaces.. Spaces.. Spaces.. and 10.5.1
Nov 15: Thread creation using pthread_create() on Leopard
Nov 13: Spaces.. Spaces.. Spaces..
Nov 07: FolderGlance, Leopard and the More... menu
Nov 06: FolderGlance and Screen Sieve now also on Leopard!
Sep 16: Mysterious window server hangs


RSS feed

Blog frontpage