Performance gap: Xcode build inside Tart VM vs Host

[BarabanovVVl]

Hello team!

We’re planning to integrate pure Tart VMs into our CI/CD flow (Jenkins → Host → SSH → VM).
The VM workflow:

• prepare environment and project via Tuist

• build project binaries with xcodebuild (via fastlane)

• run UI and Unit tests.

Environment:

• Host & VM: macOS Sequoia (latest)

• Host machine: Apple M1 (8 cores, 16 GB RAM)

• VM: 100% CPU and memory allocated

• Spotlight indexing disabled (host and VM)

• Animations, screensavers etc. disabled

• Root disk created with performance optimization flags:

• --root-disk-opts="sync=none,caching=cached"

• The VM image is created manually, very close to the configuration produced by Packer (custom-built image).

Observations:

• On host: xcodebuild full project build takes ~307 seconds.

• Inside Tart VM: same build takes ~400–470 seconds.

• Environment, dependencies, and build commands are identical.

Questions:

1. Do you have general recommendations for resource allocation (CPU/RAM/disk) for Tart VMs based on host capacity?

2. Are there any best practices to reduce the Xcode build performance gap between host and VM?

Thx!

[fkorotkov]

Usually tart run --root-disk-opts="sync=none,caching=cached" does the trick and 20% difference might be expected due to disk performance (there is a toll of running guest APFS on top of host APFS).

There is new ASIF format in Tahoe #1094 which should fix this issues but we haven't run performance tests for xcodebuild specifically. We are planning to do it in the end of September after macOS Tahoe is GA. If you'd like you can try it out with Tahoe RC, note that you'll need to create the VM from IPSW since non or our VMs is using ASIF yet.

[BarabanovVVl]

Okay, thanks! Then we’ll wait for the new release and the transition of our runners to stable macOS Tahoe.

Regarding the resource allocation question: is it fine to allocate all host resources (CPU/RAM) to the VM, considering that nothing else is running on the host except the VM?

[fkorotkov]

Yeah, totally fine. CPU is virtual and Virtualizaiton.Framework doesn't have CPU pinning so vCPUs will jump between cores.

As for memory, it's also dynamically allocated and in the worst case will swap to SSD. There is no real reason to try to have extra buffer.

[BarabanovVVl]

Thanks a lot for the answers, you’re doing an awesome job! 🙌

[BarabanovVVl]

Hi again!
A couple more questions for you — maybe your team has already tried this:

1. Is the workaround with --root-disk-opts="sync=none,caching=cached" needed on macOS Tahoe? Does it actually improve performance?

2. When creating an image with the --disk-format asif flag, the disk size is allocated dynamically, even if the --disk-size flag is provided. Does this have any impact on the VM’s performance?