How can I begin to diagnose slow swift format runs?

[squarefrog]

Over the past couple of days we've noticed running swiftformat on our CI mac takes significantly longer than locally.

For example, heres a run on our CI mac (Ventura 13.6):

$ swiftformat --version
0.52.10

$ swiftformat --lint .
Running SwiftFormat...
(lint mode - no files will be changed.)
Reading config file at /tmp/gitlab-runner-builds/351002/.swiftformat
SwiftFormat completed in 255.76s.
0/1937 files require formatting, 4 files skipped.

Versus my local mac (Sonoma 14.1.1)

$ swiftformat --version
0.52.10

$ swiftformat --lint .
Running SwiftFormat...
(lint mode - no files will be changed.)
Reading config file at /Users/paulwilliamson/Developer/ios-app/.swiftformat
SwiftFormat completed in 1.08s.
0/1937 files require formatting, 6 files skipped.

Both are M1 macs with 16 GB ram.

Is there any way to trace where significant time is being spent when linting?

[nicklockwood]

Running locally with --verbose and --cache ignore should give you a sense of which files are taking a long time to process (though not necessarily which rule).

To solve this you might want to consider checking the cache file into your repository, or finding some other way to allow your CI server to reuse it between builds. You can set a custom path for your cache using the --cache option, and it will be updated in place.

[squarefrog]

Great thanks Nick I’ll give that a go!

[squarefrog]

OK, the plot thickens.. Running the following command:

swiftformat --verbose --cache ignore --lint .

Completes in 10 seconds on the CI mac. That got me thinking perhaps theres an issue with our CI cache. So I cleared it out, then rerunning completes linting in less than a second.

I'll look into solving this long term, but I consider this an issue with our setup rather than swiftformat itself, therefore I'll close this ticket.

For future reference, if I had properly read the Readme file, I would have seen this tip to use a cache per project: https://github.com/nicklockwood/SwiftFormat#cache

Thanks again for the tip Nick!

[nicklockwood]

A lot of CI setups would allocate random machines for each build, or create a fresh machine each time from a Docker image or whatever, in which case you wouldn't expect the cache to be preserved. The best way to be certain is to define the cache location yourself and explicitly ensure that the file is preserved.

Note that the cache is also cleared whenever you upgrade SwiftFormat or change the configuration, so it may just be that it was slow for the first run after an upgrade.

[squarefrog]

This is a good point. Our CI is a self-managed cloud mac from macstadium, but with a custom cache path we should be able to share this cache via artefacts without any further issue.