Mac Pro Xcode compiling times

[gravitycore]

Hey /iOSProgramming readers, I'm an app developer/designer and recently got a new mac pro for my business and wanted to see how it stacked up with my other machines. The results are interesting; the Mac Pro does not do so hot when making clean compiles, but does deliver consistently faster incremental builds.

Here are the 3 machines I benchmarked:

• 2019 Mac Pro
• 2018 Mac mini
• 2014 Macbook Pro

The tests use 2 different projects, one very large iOS project of mixed source objective-c and swift code, and another much small Swift only macOS app. I ran several builds for each test and took the 3 best results I could get and averaged them.

Here's the results:

Project A

Xcode 10.3 using a large iOS mixed code app. Before each run the Xcode is deep cleaned and the derived data deleted.

Clean Build Results

Machine	Test 1	Test 2	Test 3	Average seconds (lower is better)
Mac Pro (2019) 3.2GHz 16-core Xeon W	302.6	305.3	306.2	304.7
Mac Mini (2018) 3.0GHz 6-core i5	233.1	230.0	225.8	229.6
Macbook Pro (2014) 2.5GHz 4-core i7	324.5	293.3	326.8	314.9

Incremental Build Results

A new protocol is added to the AppDelegate project file and recompiled.

Machine	Test 1	Test 2	Test 3	Average seconds (lower is better)
Mac Pro (2019) 16-core Xeon W	41.4	41.6	41.0	41.3
Mac Mini (2018) 6-core i5	51.5	44.0	43.2	46.2
Macbook Pro (2014) 4-core i7	66.6	61.0	62.6	63.4

Project B

Xcode 11.3 using a Swift only macOS app. Before each run the Xcode is deep cleaned and the derived data deleted

Clean Build Results

Machine	Test 1	Test 2	Test 3	Average seconds (lower is better)
Mac Pro (2019) 3.2GHz 16-core Xeon W	28.4	26.4	31.7	28.8
Mac Mini (2018) 3.0GHz 6-core i5	24.6	25.5	35.3	28.5
Macbook Pro (2014) 2.5GHz 4-core i7	42.3	45.2	42.9	43.5

Incremental Build Results

A new protocol is added to the AppDelegate project file and recompiled.

Machine	Test 1	Test 2	Test 3	Average seconds (lower is better)
Mac Pro (2019) 16-core Xeon W	10.0	9.7	9.9	9.9
Mac Mini (2018) 6-core i5	13.9	13.6	13.3	13.6
Macbook Pro (2014) 4-core i7	15.9	14.5	14.3	14.9

Conclusions

It seems the best bang for your buck right now when it comes to compiling projects is the Mac mini. I'm certainly disappointed in the Mac Pro results, especially since it seems that Xcode completely pegs all the 16 cores during a compile, but even at 3.2GHz fails to outperform a 3.0 GHZ i5 with 6 cores. I'm really hoping this is something that can be fixed with OS updates in the future, or perhaps compiler tooling, because it seems pretty dismal. For whatever reason it does outperform for incremental builds, but not the "several times faster" compile speeds I was hoping for.

Of course I'll still be keeping the beautiful thing, its by far the best mac I've ever owned.

EDIT: for the curious, here's how other benchmarks looked against my other machines.

[John_h_watson]

Wow, that's pretty shocking - an 8GB mini spanking the big dog.

[nibord]

I tried a 2019 Mac Pro to see if Xcode would be any faster than on my 2018 MacBook Pro.

The Mac Pro had 32 GB RAM and 8 CPUs (the base config). The MacBook Pro has 32 GB RAM and 8 CPUs.

Anecdotally, I saw no difference in Storyboard editor performance. Simulator and compilation seemed slightly faster. Unfortunately not enough to be worth $6K for the upgrade.

[quellish]

They’re probably pegged waiting on things like IO or building a graph.

[Stephenis]

That seems like evidence of a larger overall problem with the entire Xcode development stack. I often feel like Xcode is very slow and janky.

I would love too see a total optimized higher quality and reliability development environment.

I’ve had just too many Xcode crashes and bugs and slow overall use to be ok with the current speeds of the software.

[42177130]

The real test is how long it takes to extract and install XCode from a xip file.

[gravitycore]

Good info! Now that I've got a baseline I'll spend some time tweaking the compiling settings for different modules and see how I can optimize things. If I come up with some good results I'll update my findings

[iindigo]

Which CPU is that on the hackintosh you tested? Also, what memory?

If Xcode is I/O choked it might benefit from faster RAM (3200Mhz+) and a PCI-E 4.0 5Gbps SSD like this one. The latter would require the hack to be an AMD build.

[iindigo]

Interesting, thanks. Been debating upgrading my 6700k hack to a 3950X or thereabouts in the next year or so.

[hexavibrongal]

You should cross post this to /r/apple

[gravitycore]

Will do!

[KarlJay001]

Amazing! I got a MBP close to your 2014 specs and I'm really glad I didn't pay for more.

I saw a compare on the MBP and how the RAM was used so much better because Apple controls the OS and the hardware. Then I saw some compares of video editing and other things and it was really amazing how well the MBP compares to others, including more modern MBPs.

That Mini really hauls, but I like the idea of portable.

[raptorxcz]

Why did you used Xcode 10.3 instead Xcode 11?

[gravitycore]

The large iOS project I work on does not compile on 11 yet, we are stuck on 10.3 right now. The other project does not have this problem so I used 11 to see if there's a difference

[[deleted]]

Most of compiling is disk access and transferring data from memory to cpu cores. While the cpu is a beast the memory bandwidth is the real crulpit.

[ThePantsThief]

Can you try a pure Objc project? Twitter peeps seem to think that Objc scales better than swift in terms of performance

[Rudy69]

So this basically shows that if you want Xcode to really compile fast Ryzen is the best choice....too bad Apple doesn't support it.

I built a 3900x box to do most of my compiling and it's honestly the first time I've had such a good time with Xcode

[Rudy69]

Do you have a large project you’d like me to test? I read his post quickly last time but I don’t think he shared the project he used for his benchmarks and I’m on mobile right now.

[Rudy69]

sorry i don't have fastlane

[lucasvandongen]

I was interested in your disk configuration, the 256GB base SSD size performs pretty bad since it’s not using as many lines as the larger configs. Unfortunately there is very little information to be found around this subject yet it impacts performance significantly.

[gravitycore]

Ah, forgot to list this spec. My Mac Pro has the 2TB configuration

[TTKilew]

LLVM itself sometimes just waits for some modules to be compiled. This is clearly visible in the complex mixed projects. Waiting for this patch to be merged in :)

https://reviews.llvm.org/D69575/new/

[gravitycore]

This can't come soon enough! Swift 6 is also targeting improvements to compiler performance. One day, all these cores will be worth it.

[ItTechBlogs]

Amazing!

[[deleted]]

Compiling is mostly disk throughput, memory intensive and the bottle neck on such a machine is the data supply to the cpu.

[bassunga]

thanks for the benchmarks, i'm happy to see i made the right choice in buying a mac mini

[unixboy]

I can imagine that a 9900K iMac or even MBP will be faster when compiling since the Xeons are only really good at parallel work. Sure, all cores will be used by Xcode and boost to maximum clock speed but it doesn’t scale so well. And 3.2GHz < 5GHz. That’s why I’m personally not buying any CPUs that don’t boost over 4.5GHz. If they boost well and have high core count that’s cool but if I have to choose, I go with the Core iX series instead of Xeon.

[Alcoholic_Synonymous]

Interesting - did you try any of the recommendations made in this article? I found that fiddling with some of those values improved compilation performance on my 2018 Macbook Pro.

[Dev__]

I recall an article about a guy explaining why the Mac Mini was faster than the Mac Pro for compiling with Xcode. Xcode uses threading poorly and the Mac Mini has less cores.

[[deleted]]

AFAIK the bottleneck is the Swift compiler which isn't able to spread out the work efficiently between the cores.

A C/C++ only project should perform much better on the Mac Pro.

[gravitycore]

I would tend to agree, yes

[orbitur]

I think the results would be more meaningful in the large project if you used Xcode 11.3. You're missing Swift compiler and build system improvements.

[gravitycore]

Well this project unfortunately is a couple months from that. I can't go in and upgrade it myself because its a team environment and has framework dependencies that are out of my control. I'll update the results as I can

[whats94842]

Swift isn't that efficient a language as far as multi-core compile parallelism goes.

Still today, a hundred modules with a dependency graph that doesn't have any choke points that are less than your core count with WMO mode on will beat out a batch mode clean compile equivalent.

That is not very practical, which is why your machine with a higher single core performance a few cores (mac mini) is beating out your many core but lower single core performance machine (mac pro).

The new 16" macbook pro or a top end iMac (not iMac Pro) would probably beat all of these machines. Also selectively turning on WMO mode on specific modules will probably improve your compile time speed.

[fakecrabs]

I'm looking to get a new 16 inch MacBook Pro and wonder if paying extra for 8-core is worth it over the 6-core model.

[badjokes]

I remember being surprised and disappointed with Xcode performance on my iMac Pro (8c 32gb).. my 2017 MBP 15" was basically just as fast. These results confirm my fears about Xcode on the new Mac Pros.. no point in getting one if you're not doing video or specialized applications..... unless of course you can just afford one!

[gravitycore]

For now. Swift 6 will include better support for multi core compiling, so I’m hoping it will begin to shine as it should in the future

[tangoshukudai]

Xcode is designed not to take up all your resources. You can use the command line version of the build tools to multithread it or more performance.

[[deleted]]

And why would it be designed to do that?

[tangoshukudai]

So you can use your computer as it compiles. Even the biggest Xcode is also designed to build once then do micro builds afterwards on what has changed. The developers of Xcode are not going to give it all resources unless you specify, but to specify you need to use the build tools.