Tuist Registry Initiative

Initiatives
1

This initiative’s main goal is to improve the SwiftPM resolution by implementing the Package Registry standard.

About

Why

When resolving dependencies, SwiftPM defaults to doing deep clones to resolve the correct version. Package Registry is a standard that allows the implementation of centralized registries, so that consumers only need to download source archives for versions they need instead of doing deep clones.

We plan to provide all packages in the Swift Package Index in a Tuist implementation of the Package Registry to improve the resolution times.

Goals

The goals of this initiative are:

  • Server implementation of the Package Registry. We’re mostly done there.
  • Implement convenient integration for:
    • Tuist projects using XcodeProj-based integration
    • Tuist projects using the default SwiftPM integration
    • Vanilla SwiftPM projects
    • Vanilla Xcode projects with the default SwiftPM integration
  • Contribute back to swift-package-manager and improve its performance
2

Hey folks :wave:

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.

1 Like