Linkdin (of all companies) published a shocking blog today on the performance of Swift build times. They claim that their project compiles faster on their lower speced MacBook Pros (and even a Mac mini) than their 12 core Mac Pros. Even though the Mac Pro is 4 years out of date, the raw number of cores gives it quit an advantage over the 4 core MacBook Pro and especially the 2 core Mac mini. What's even more shocking, is that when they lowered the number of threads available to the compiler, their build times actually went up. It's an interesting article and worth reading. I decided to test their numbers with my own project.
First, I tried building from the command line, cleaning each time to get consistent results:
time xcodebuild -workspace Engagement.xcworkspace -scheme Engagement -sdk iphoneos -configuration Debug clean build | xcprettyThe results were underwhelming:
real 4m10.878s
user 19m56.674s
sys 2m56.431s
real 4m33.931s
user 15m54.428s
sys 2m26.276s
real 4m19.398s
user 17m24.258s
sys 2m35.373s
real 4m22.492s
user 17m24.521s
sys 2m37.316s
From these numbers, it doesn't seem like the setting has all that much affect on the build times of this app. But then I thought about how I normally build the app. Clean builds are rare. What really matters is cached builds.
xcodebuild -workspace Engagement.xcworkspace -scheme Engagement -sdk iphoneos -configuration Debug build | xcprettyreal 0m51.314s
user 1m11.009s
sys 0m11.621s
real 0m53.449s
user 1m11.296s
sys 0m11.755s
real 0m51.771s
user 1m10.992s
sys 0m11.681s
real 0m43.833s
user 1m3.228s
sys 0m9.599s
Most of these I only ran once, but I did run the "no clean 7 thread" and "no clean default" one several times to verify that there was a consistent difference.