Scaling Swift Package Manager builds

I added a product to a Package.swift with few additional transitive dependencies and the time to start the build went from seconds to several minutes. Any suggestions?

~/demo  $  xcode-select --print-path
~/demo  $ git clone
Cloning into 'firebase-ios-sdk'...
remote: Enumerating objects: 64, done.
remote: Counting objects: 100% (64/64), done.
remote: Compressing objects: 100% (51/51), done.
remote: Total 75333 (delta 20), reused 28 (delta 12), pack-reused 75269
Receiving objects: 100% (75333/75333), 32.92 MiB | 19.70 MiB/s, done.
Resolving deltas: 100% (53117/53117), done.
~/demo  $ cd firebase-ios-sdk/
~/demo/firebase-ios-sdk (master) $ git checkout pb-spm-firestore
Branch 'pb-spm-firestore' set up to track remote branch 'pb-spm-firestore' from 'origin'.
Switched to a new branch 'pb-spm-firestore'
~/demo/firebase-ios-sdk (pb-spm-firestore) $ time swift build
[92/617] Compiling FirebaseFunctions FUNUsageValidation.m

real	12m39.951s
user	14m2.008s
sys	0m45.306s

Looks like we are spending a lot of time in TargetSourcesBuilder. My first guess would be that it is related to grpc listing all their source files long form in the manifest which may not be efficiently handled by TargetSourcesBuilder today.


@NeoNacho Thanks for the quick response. I'll try some experiments with restructuring the gRPC and BoringSSL directory structures to support a simple Package.swift build specification.

Unfortunately that could make it harder to get a PR accepted by those teams since they support many other build systems.

Confirmed that switching from a file list to directories, excludes, and a symbolic link for the publicHeadersPath reduced the time from twelve minutes to less than a minute. Details here.

Glad that you could make it work. Would appreciate if you could file a bug for this, we should optimise TargetSourcesBuilder, it shouldn't be this slow.

Done - Thanks for your help!

1 Like