When LinkedIn embraced Swift and rebuilt its flagship iOS app using (mostly) Swift, I spent a good amount of time profiling the new compiler characteristics. At that time (mid 2015), it was clear that the compiler was CPU-bound (I/O and memory had no visible impact on build speed). However, the build times were determined primarily by the number of cores and threads available to the compiler, more so than by the CPU clock speed.
Based on this analysis, we decided to use 12-core MacPros for core development, and we saw a significant (2-3 times) speedup of our builds compared with quad-core laptops.
As you can see, 12-core MacPro is indeed the slowest machine to build our code with Swift, and going from the default 24 jobs setting down to only 5 threads improves compilation time by 23%. Due to this, even a 2-core MacMini ($1,399.00) builds faster than the 12-cores MacPro ($6,999.00).
For machines with more than 4 cores consider reducing number of concurrent jobs allowed for Xcode - until the concurrency issue described above has been resolved.
Be careful with disabling Spotlight indexing for ~/Library/Developer as it will also exclude dSYM symbol files of builds and archives.
Xcode uses Spotlight to search for matching dSYM files when symbolicating crash reports. Turning off Spotlight indexing for them might break crash symbolication completely.
This smells like a hardware or kernel issue.
Blaming any particular component is premature. “There Is A Bug Exposed By Swift 3 Running on Sierra” is all we know.
Core count doesn’t seem to matter either, we observed the same issue on 4-core Xeon setups. Seems to be Xeon-specific.
The bug report is here.
See also: Colin Cornaby.
Stay up-to-date by subscribing to the Comments RSS Feed for this post.