vscode on save got incredibly slow after rubocop 1.90 upgrade + UseProjectIndex

[HoneyryderChuck]

Description

Ruby LSP Information

### Ruby LSP Information

#### VS Code Version

1.137.0

#### Ruby LSP Extension Version

0.10.6

#### Ruby LSP Server Version

0.26.11

#### Ruby LSP Add-ons

- Tapioca (0.1.3)
- Ruby LSP Rails (0.4.8)
- RuboCop (1.90.0)

#### Ruby Version

4.0.6

#### Ruby Version Manager

asdf

#### Installed Extensions

<details>
<summary>Click to expand</summary>

- claude-code (2.1.270)
- remote-containers (0.469.0)
- ruby-extensions-pack (0.1.14)
- ruby-lsp (0.10.6)
- sorbet-vscode-extension (0.3.47)
- terraform (0.2.5)
- vim (1.32.4)
- vscode-containers (2.5.0)
- vscode-jsonnet (0.7.4)
</details>

#### Ruby LSP Settings

<details>
<summary>Click to expand</summary>

##### Workspace

```json
{
  "indexing": {
    "excluded_patterns": [
      "/bin/**",
      "/cypress/**",
      "/front-end/**",
      "/kubernetes/**",
      "/public/**",
      "/secrets/**",
      "/semgrep/**"
    ],
    "excluded_gems": [
      "annotate",
      "better_errors",
      "binding_of_caller",
      "brakeman",
      "bullet",
      "bundler_audit",
      "danger",
      "danger-rubocop",
      "debase",
      "guard",
      "guard-rspec",
      "knapsack_pro",
      "listen",
      "parallel_tests",
      "rspec_junit_formatter",
      "rubocop",
      "rubocop-daemon",
      "rubocop-rails",
      "rubocop-rspec",
      "ruby-debug-ide",
      "ruby-lsp",
      "solargraph",
      "spring-commands-rpsec",
      "squasher",
      "super_diff"
    ]
  }
}

User

{
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "auto"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {
    "excluded_patterns": [
      "/bin/**",
      "/cypress/**",
      "/front-end/**",
      "/kubernetes/**",
      "/public/**",
      "/secrets/**",
      "/semgrep/**"
    ],
    "excluded_gems": [
      "annotate",
      "better_errors",
      "binding_of_caller",
      "brakeman",
      "bullet",
      "bundler_audit",
      "danger",
      "danger-rubocop",
      "debase",
      "guard",
      "guard-rspec",
      "knapsack_pro",
      "listen",
      "parallel_tests",
      "rspec_junit_formatter",
      "rubocop",
      "rubocop-daemon",
      "rubocop-rails",
      "rubocop-rspec",
      "ruby-debug-ide",
      "ruby-lsp",
      "solargraph",
      "spring-commands-rpsec",
      "squasher",
      "super_diff"
    ]
  },
  "erbSupport": true,
  "featureFlags": {},
  "sigOpacityLevel": "1"
}

```

Reproduction steps

The reproduction is hard without a sufficiently large app. As mentioned above, after upgrading to rubocop 1.90, and enabling the UseProjectIndex config, which enables their rubydex integration, rubocop-on-save suddenly started taking >30s, up to the point where I'm constantly pressing "Skip" when running the rubocop formatter.

My understanding is that ruby-lsp's rubocop integration just runs rubocop cli command on save. My guess, and based on what's written here, is that when the integration is enabled, rubocop will reindex the whole project before running cops.

This may not be a ruby-lsp problem, but it does result in visible DX impact for ruby-lsp users, which will perceive the tool as being slow. This being an experimental flag, the goal is to document this, so that the integration can be reworked so that rubocop's add-on piggy backs on ruby-lsp's already indexed workspace and skips this step.

[vinistock]

Thank you for the report. This is an intersection between the linter and the LSP.

Re-analyzing the entire codebase is expensive, so the most efficient way to structure this type of mechanism is to have the LSP own the analysis (the Rubydex graph in this case) and keep it up to date doing the minimum amount of work possible when files are modified.

The linter should only receive the up to date analysis and run its rules on top of it, avoiding re-analyzing more than once for a group of edits.

It depends a lot on how RuboCop structured this. If it is creating a fresh Rubydex graph and running the analysis from scratch on every single lint, then it will be unbearably slow without a doubt—but that's not the right way to integrate.

For this to work in the way it was intended and have a good integration with the LSP, RuboCop's Runner needs to accept a graph managed externally by the LSP, so that it always operates on an up to date graph.

All of that said, there are still some performance improvements that we have planned for incrementally changing the graph, which is the main reason why the Ruby LSP's own migration to Rubydex is still in beta #4103. We can only pass a populated graph to RuboCop on the beta version as it does not exist in stable releases yet.

To summarize:

• We need to finish the performance improvements we have planned for Rubydex
• That allows us to cut a stable release of the Ruby LSP fully backed by Rubydex
• RuboCop needs to provide a way to operate on an externally managed Rubydex graph
• Then we can make the change in the Ruby LSP to pass its graph to RuboCop

[HoneyryderChuck]

I see, thx for the thorough explanation. Do you think it's reasonable to keep this open until the rubocop integration uses the indexer from ruby-lsp?

[vinistock]

Yes, it does. I pinned the issue to avoid the stale mark.