Reports of Xcode 11 building slow: 50% increase in build times?
We recently had a call with a customer who has been experiencing slow run-times after moving to Xcode 11. Have you experienced similar issues? We want to know!
The release of Xcode 11 has been eagerly anticipated since the sweeping changes announced at WWDC this year. Development and product teams alike are elated to stop speculating and start testing.
No code release goes 100% smoothly, and this release is no exception. The release for Xcode 11 was September 24th, so on September 25th, a thread was started on Stack Overflow for “Xcode 11 extremely slow - A known problem?” The post has been updated over the last 12 days, nine people reported the same issue by “upping” the thread, five have posted comments. Neither of the two suggested work-arounds have meet with acceptance as of yet.
On Friday, October 4, MacStadium had a call with a client experiencing this issue first-hand. After the update applied on October 2nd (Xcode 11.2 (11B41)), the results did not show much improvement since the release.
In a nutshell, the bare-metal builds are at about 150% of the run-time compared to Xcode 10. Virtual machines show a similar increase. This has created queueing issues for the client, and they asked us for input from the MacStadium community on any solutions or work-arounds.
In this case, this client has decided on a work-around: more VMs on the same hardware. They were running one VM per 12-core Mac Pro at MacStadium, using vSphere as their virtualization technology. Testing using two VMs per Mac Pro showed a 200% increase in time compared to bare metal pre-Xcode11; however, doubling the nodes did address the queue issue for their dev staff. Ultimately queue time + build time was less desirable than the flat +50% time for the hypervisor to have two instances.
This team has also prioritized their testing with Orka. The 30% time savings Orka provides compared to VMware virtualization will not fully compensate for the added lag of Xcode 11, but it would help. Running at a projected 140% of the old run times (30% savings x 200%) is very attractive given there is no full solution in sight.