Hey folks 
I wanted to provide an update with some initial performance findings that we gathered from testing our registry with tuist/tuist and our staging server environment.
We will also soon open the registry to initial testers – either tomorrow or early next week. We’ll provide the details here and in Slack.
Measurements
Here are the numbers I gathered (note the gathered numbers are from 1-2 runs, so take them with a pinch of salt)
Without registry :
Cold run without registry and with cache (Saving cache time 10s, install dependencies 1 min 7 s - 1 min 17s): Add actions cache · tuist/tuist@7dddb0b · GitHub
Warm run without registry and with cache (restore cache 8s, ~388 MB, install dependencies 20 s): Add actions cache · tuist/tuist@7dddb0b · GitHub
With registry:
Cold run with registry and cache (install dependencies 51 s - 55 s): Add actions cache · tuist/tuist@bce21b1 · GitHub
Warm run with registry and cache (restore cache 2s, ~71 MB - install dependencies 23 s): Add actions cache · tuist/tuist@bce21b1 · GitHub
Findings
The time savings for downloading and uploading the CI cache of the .build directory are significant – around 80 %.
The resolution step itself is faster by around 20 %. We expected slightly better numbers and we believe that we can contribute back to the swift-package-manager to improve those further.
Primarily, the archives could be downloaded in parallel, whereas now they are downloaded serially. The downloads occur here. When the loop is run in parallel, the download part of the resolution is 80 % faster – down to around 2 seconds from 13. We will try to open a PR with this change. Unfortunately, once and if merged, the change would only ship with the next Swift version.
We’ll also investigate if there are other parts of the resolution that can be sped up.