-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Significant increase of compilation speed #773
Comments
Hey @ch1e, could you please tell us a big more about your project. How big is it and how you measure the 1100 seconds? It it the whole PS just a few days ago we ran IO benchmarks and results are very promising especially on small files. |
Hey @fkorotkov, thank you for the reply. Our project is relatively big, with the main part of the app written in React Native and also plenty of native code. So we consider a 10-minute build time to be more or less acceptable. My measurements are quite simple: currently, we have two ways of running iOS builds - directly on a hardware macOS agent or by executing |
Can I also double check with you that you set Tart's VM resources to match the host CPU/memory. By default Tart VMs will only use 4 cores and 8GB of memory. You can override it by defining
|
Sure! I have this code in
As far as I understand, it does the same job: I checked the configuration of the created vm and everything seems to be correct (8 cores and 16g memory) |
Thank you for the confirmation! 2x slowness is indeed very weird. We are not familiar with Also do you use one of our images or you build it yourself? If you have your own images please make sure that Spotlight indexing is disabled and that you increased limit for open files. |
Actually, Regarding images: we use ones based on your Do you think it may be a good idea to prepare an example project with our basic tooling (React Native, Fastlane), try to measure compilation speed on it, and share it with you to provide more context? |
That would be wonderful! You'll be a hero by providing a reproducible project. We tend to use some syntactic tests and https://github.com/devMEremenko/XcodeBenchmark for validations. |
Hey @fkorotkov On my machine (M1 Pro, 32GB RAM, macOS 14.4):
On our CI agent (oakhost Mac mini M1, 16GB RAM, macOS 13.6):
To be honest, I'm unsure how to interpret these numbers. While the performance on my local Macbook seems acceptable, the performance on the oakhost Mac mini appears questionable. I'm not sure if, by increasing compilation speed, we can achieve numbers similar to the ones we are currently experiencing in our project. Do you have any ideas? Alternatively, is there any possibility that we have something wrong with the setup on the oakhost machine? |
Is there an option to upgrade to Sonoma on the agent? Could you please also make sure Spotlight indexing is disabled on the host:
|
We plan to upgrade the OS version, but I am unable to test the same agent with Sonoma right now. Do you think this could be the reason for the issue? |
Closing it for now since it seems reproducing on a particular host using an old macOS version. |
We've been utilizing Tart with Cirrus CLI on our self-hosted TeamCity CI infrastructure and have found it to be a valuable addition. However, we're currently encountering a notable performance degradation in compilation speed compared to building on hardware agents.
The issue arises during the execution of
xcodebuild
(via fastlane gym). While the CPU performance, as measured with Geekbench 6 on the VM, remains almost identical to that of the host machine, the compilation time has increased dramatically. We've observed a nearly twofold increase, from approximately 600 seconds on the host machine to around 1100 seconds inside the Tart VM.Upon researching potential causes, I came across a discussion (#420) indicating a possible degradation of around 30%. However, our observed degradation is much higher. Currently, we're unable to use the
--dirty
mode to potentially speed up IO due to the issue outlined in #567However, I'd like to inquire if there are any other potential ways to address the performance degradation? I would be extremely grateful for any response or assistance in resolving this issue. Thanks!
The text was updated successfully, but these errors were encountered: