SwiftLint Compile Times Extremely Slow

[DomenicBianchi01]

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

Describe the bug

• When compiling the app with the SwiftLint SPM plugin installed, the compile times are extremely slow.
• It looks like the culprit is SwiftSyntax

Environment

• SwiftLint version: 0.52.3
• Xcode version: 14.3.1
• Installation method: SPM

[DomenicBianchi01]

Related issue: #4261

[marcelofabri]

Not really related, that issue is about the runtime performance of SwiftLint. Optimizing for compilation times hasn't been a goal of SwiftLint. IMO the real issue here is how SPM works if this is happening in every build.

I personally always recommend people using a pre-built binary if they don't want to pay the compilation cost.

[jpsim]

You're correct to note that SwiftSyntax is responsible for the bulk of the compilation time. That's also tracked here: apple/swift-syntax#1194

This is why most users should be using pre-built SwiftLint binaries, which the SwiftPM plugin should be using by default. If that's not happening for you for some reason, please share more information.

[anton-plebanovich]

Not sure if related or if should I create a separate issue. I'm facing an issue of huge lint times when I try to pass concrete files to lint. In my project, it takes ~1 second to perform full lint of ~250 files and ~12 seconds when I pass ~60 files. Version 0.52.4.

It takes ~1 second on Version 0.51.0 for example for the same 60 files.

My teammate on a different project reported ~10 mins lint time on bigger file counts and on slower machines.

[jpsim]

How does that compare with running swiftlint as installed from Homebrew from your command line?

[anton-plebanovich]

How does that compare with running swiftlint as installed from Homebrew from your command line?

If that's a question for me, I use Cocoapods and binary there so not sure if it makes sense to check binary from Homebrew.

[Mordil]

We made an upgrade to one of our projects that necessitated embedding & committing almost 100 new files to our project that previously were codegen as part of a SwiftPM build plugin.

Even after adding a globstar pattern to ignore those files, we're seeing SwiftLint go from 3s tops to now 150s in some cases.

This is with the Swift Plugin version of SwiftLint, on both 0.51 and 0.52

We have 24 opt-in rules enabled, and 12 rules turned off. 1 rule is deprecated - unused_capture_list

We do have the explicit_self analyzer rule enabled as well, but even disabling it we're still seeing the massive increase in runtime

The following screenshots are with one with the analyzer rule, and without

analyzer ON	analyzer OFF

[Mordil]

Ah, it looks like my comment likely relates to #5018 instead

[fl034]

You're correct to note that SwiftSyntax is responsible for the bulk of the compilation time. That's also tracked here: apple/swift-syntax#1194

This is why most users should be using pre-built SwiftLint binaries, which the SwiftPM plugin should be using by default. If that's not happening for you for some reason, please share more information.

@jpsim Is there a way to offer a Swiftlint binary as Xcode plugin?
In a Swift package, using the Xcode plugin seems to be the only way to lint the code.

[akkyie]

You're correct to note that SwiftSyntax is responsible for the bulk of the compilation time. That's also tracked here: apple/swift-syntax#1194

This is why most users should be using pre-built SwiftLint binaries, which the SwiftPM plugin should be using by default. If that's not happening for you for some reason, please share more information.

In my environment, pre-built binaries are used in SwiftLint 0.51.0, but starting from 0.52.0, it requires building from the source code including SwiftLintFramework, ArgumentParser, SwiftSyntax, etc.
I have confirmed the same behavior in Xcode 14.3.1 and Xcode 15.1. I'm using the plugin in a Swift Package that is used by an iOS app target.

Perhaps the platforms: conditions are not working as expected...?
0.51.0...0.52.0

Has anyone else confirmed the same behavior?