Adding `--force-exclude` makes SwiftLint pathologically slow

[puls]

New Issue Checklist

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

Describe the bug

When I add --force-exclude to have SwiftLint, it gets orders of magnitude slower, even when linting only a single file that's not excluded.

Complete output when running SwiftLint, including the stack trace and command used

$ time SWIFTLINT_PATH=~/path/to/checkouts/SwiftLint swift run --package-path "${SWIFTLINT_PATH}" swiftlint --force-exclude Just/One/File.swift 
Building for debugging...
Build complete! (0.28s)
Linting Swift files at paths Just/One/File.swift
Linting 'File.swift' (1/1)
Done linting! Found 0 violations, 0 serious in 1 file.
SWIFTLINT_PATH= swift run --package-path "${SWIFTLINT_PATH}" swiftlint    38.41s user 13.78s system 129% cpu 40.359 total

$ time SWIFTLINT_PATH=~/path/to/checkouts/SwiftLint swift run --package-path "${SWIFTLINT_PATH}" swiftlint Just/One/File.swift 
Building for debugging...
Build complete! (0.17s)
Linting Swift files at paths Just/One/File.swift
Linting 'File.swift' (1/1)
Done linting! Found 0 violations, 0 serious in 1 file.
SWIFTLINT_PATH= swift run --package-path "${SWIFTLINT_PATH}" swiftlint   0.21s user 0.09s system 41% cpu 0.716 total

Environment

• SwiftLint version (run swiftlint version to be sure)?
  • 23e4db3e5fc3177accf2d4626150c5b0bbb9ec48
• Installation method used (Homebrew, CocoaPods, building from source, etc)?
  • It's a Swift Package Manager dependency inside Xcode and I'm calling swift run from its checkout location in DerivedData. But the same behavior happens with version 0.50.3 from Homebrew.
• Paste your configuration file:

excluded:
  - API/**
  - ci_scripts/**
  - ./**/.build

opt_in_rules:
  - anonymous_argument_in_multiline_closure
  - convenience_type
  - fatal_error_message
  - flatmap_over_map_reduce
  - force_unwrapping
  - file_types_order
  - implicit_return
  - implicitly_unwrapped_optional
  - indentation_width
  - missing_docs
  - modifier_order
  - redundant_type_annotation
  - weak_delegate

disabled_rules:
  - force_unwrapping
  - line_length
  - nesting

file_types_order:
  severity: error
  order:
    - main_type
    - supporting_type
    - extension
    - preview_provider
    - library_content_provider

type_name:
  min_length: 2

identifier_name:
  min_length: 2

missing_docs:
  error:
    - open
    - public
  warning:
    - internal
  excludes_trivial_init: true
  excludes_inherited_types: false

trailing_comma:
  mandatory_comma: true

cyclomatic_complexity:
  ignores_case_statements: true

• Are you using nested configurations?

  • No

• Which Xcode version are you using (check xcodebuild -version)?

  • Xcode 14.1, Build version 14B47b

• Do you have a sample that shows the issue? Run echo "[string here]" | swiftlint lint --no-cache --use-stdin --enable-all-rules to quickly test if your example is really demonstrating the issue. If your example is more complex, you can use swiftlint lint --path [file here] --no-cache --enable-all-rules.

  • All the rules are working correctly

[SimplyDanny]

I can confirm the runtime difference for the 0.50.3 release. When building the commit 23e4db3e5fc3177accf2d4626150c5b0bbb9ec48, I don't see differences, though.

The binaries built by SPM are generally a bit slower, I guess. But I don't see a difference with or without the --force-exclude flag.

The profiler shows that in the 0.50.3 release, the function parallelMap(transform:) causes the overhead.

That said, the next release seems to resolve the issue.

[balavor]

@SimplyDanny Is there a way to release that fix in a fix release? We had about 7-10 rules to exclude generated files recursively, and our swiflint script took about 1 minute vs 12 seconds if we just remove these rules.

[SimplyDanny]

@jpsim: Is there anything blocking a new release?

[pavel-trafimuk]

Any news about it? Also see strange slowing of linting, even dramatically. Also have --force-exclude

[SimplyDanny]

Please try 0.51.0.

[SimplyDanny]

Is this still an issue for you guys?

[simba909]

I was able to reproduce this reliably before but as of 0.52.4 I don't seem to be able to 🎉 Don't know what changed (or if the issue author can reproduce) but this might be resolved