Replies: 2 comments
-
Language servers for Ruby typically consume lots of memory because the language has no packaging/import system and all requires add constants to the global namespace (which means that the language server must know about all available declarations regardless of the files being edited since they can be referenced from anywhere). That said, 15GB seems like a lot. Unless your application is gigantic, I suspect the LSP might be indexing files that are unnecessary. You could try checking the internal structure of our index to see if there are any files being indexed that you don't care about (e.g.: fixtures). After figuring that out, you can use the indexing settings to exclude those files from the indexing process. Here's one way to check what's being indexed. Start an IRB session using the Ruby LSP's composed bundle (to be able to require the LSP's code): BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle exec irb Then index and inspect the structure of the index require "ruby_lsp/internal"
index = RubyIndexer::Index.new
index.index_all
# Reach into the internal state to check which URIs (files) were indexed
uris_to_entries_hash = index.instance_variable_get(:@uris_to_entries)
# Inspect the URIs that were indexed. Do you see anything irrelevant like fixtures or development
# dependencies?
puts uris_to_entries_hash.keys If you identify things you want to exclude, here are the indexing configurations. |
Beta Was this translation helpful? Give feedback.
-
@vinistock Thanks! This was precisely the issue. This project uses CDK to build, and it creates cdk.out/asset dirs as part of the deployment with multiple copies of the entire ruby environment! It was loading the about and all the gems a few 100 times!! |
Beta Was this translation helpful? Give feedback.
-
Is it normal for ruby-lsp to use lots of RAM?
I'm running it in a rails app on Linux with neovim and am seeing over 15GB of resident RAM
Happy to help debug, but not sure where to start
Beta Was this translation helpful? Give feedback.
All reactions