Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruby LSP Indexing is very slow on version 0.19.0 #2671

Open
jmschp opened this issue Oct 4, 2024 · 7 comments
Open

Ruby LSP Indexing is very slow on version 0.19.0 #2671

jmschp opened this issue Oct 4, 2024 · 7 comments
Assignees
Labels
bug Something isn't working vscode This pull request should be included in the VS Code extension's release notes

Comments

@jmschp
Copy link

jmschp commented Oct 4, 2024

Description

Ruby LSP Information

VS Code Version

1.91.1

Ruby LSP Extension Version

0.8.2

Ruby LSP Server Version

0.19.0

Ruby LSP Addons

  • Ruby LSP Rails

Ruby Version

3.3.5

Ruby Version Manager

asdf

Installed Extensions

Click to expand
  • better-comments (3.0.2)
  • cucumberautocomplete (3.0.5)
  • vscode-erb-beautify (0.5.0)
  • pyright (1.1.327)
  • vscode-zipfs (3.0.0)
  • vscode-markdownlint (0.56.0)
  • vscode-eslint (3.0.10)
  • dotenv-vscode (0.28.1)
  • gitlens (15.5.1)
  • prettier-vscode (11.0.0)
  • vscode-pull-request-github (0.92.0)
  • todo-tree (0.0.226)
  • vscode-drawio (1.6.6)
  • prettier-sql-vscode (1.6.0)
  • haml (1.4.1)
  • mongodb-vscode (1.7.0)
  • vscode-docker (1.29.2)
  • debugpy (2024.6.0)
  • python (2024.12.3)
  • vscode-pylance (2024.8.1)
  • cpptools (1.21.6)
  • cpptools-extension-pack (1.3.0)
  • cpptools-themes (2.0.0)
  • vscode-versionlens (1.14.2)
  • material-icon-theme (5.11.1)
  • platformio-ide (3.3.3)
  • vscode-xml (0.27.1)
  • vscode-yaml (1.15.0)
  • trailing-spaces (0.4.1)
  • ruby-lsp (0.8.2)
  • code-spell-checker (4.0.13)
  • code-spell-checker-portuguese-brazilian (2.2.1)
  • vscode-stylelint (1.4.0)
  • highlight-matching-tag (0.11.0)
  • markdown-all-in-one (3.6.2)

Ruby LSP Settings

Click to expand
Workspace
{}
User
{
  "enableExperimentalFeatures": false,
  "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": "asdf"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true
}

Reproduction steps

  1. Open VS Code
  2. Ruby LSP starts indexing
  3. On this new version (0.19.0) Indexing is a whole lot slower! 😢 It starts to slow down at 30% on my case.

Code snippet or error message

@jmschp jmschp added bug Something isn't working vscode This pull request should be included in the VS Code extension's release notes labels Oct 4, 2024
@vinistock
Copy link
Member

vinistock commented Oct 4, 2024

Thank you for the report. I think this is likely related to the fact that we started handling multibyte characters correctly in #2619.

While I understand that the slow down is not ideal, it's a cost we have to pay to handle non ASCII characters used in Ruby appropriately. For ASCII-only sources, there are optimizations we apply to ensure better performance, but calculating the appropriate code unit locations for multibyte sources is expensive by nature.

And we must do it during indexing otherwise users of multibyte characters will get features offset by an incorrect number of bytes, like developers using Japanese characters as part of their Ruby code.

Are you using a lot of multibyte characters in your codebase? For example, characters with accents like â, Japanese characters or emojis (even in comments)?

@jmschp
Copy link
Author

jmschp commented Oct 4, 2024

This is a new codebase I am working on, it big and I still don't know it very well yet. But I don't think we have a lot of non ASCII characters. It's an application for USA market only, everything is in English.

It is taking a bit more than 4 minutes to index.

@andyw8
Copy link
Contributor

andyw8 commented Oct 4, 2024

@jmschp I'd be curious to see the times for v0.18.4 vs v0.19.0.

(You can temporarily add ruby-lsp in your Gemfile to use a specific version).

@jmschp
Copy link
Author

jmschp commented Oct 4, 2024

@andyw8

I used the following Regular Expression [^\x00-\x7f] to search the code base, and found 64 results in 9 Ruby files.

Times:

  • 0.18.4 -> 0′44″
  • 0.19.0 -> 4′12″ 😢

@vinistock
Copy link
Member

That's a crazy increase. You're not indexing tests by any chance? Do you use test or spec for the directory?

@jmschp
Copy link
Author

jmschp commented Oct 4, 2024

@vinistock

I use spec.

I have the ruby-lsp-rspec (0.1.14) installed, but it is not specified in the Gemfile.

@vinistock
Copy link
Member

Did you already exclude the spec directory from indexing?

If not, can you please try this and let us know if indexing is faster? We should probably exclude spec by default like we do for test.

{
  "rubyLsp.indexing": {
    "excludedPatterns": ["**/spec/**.rb"],
  },
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working vscode This pull request should be included in the VS Code extension's release notes
Projects
None yet
Development

No branches or pull requests

4 participants