-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Very slow startup time on WSL #3704
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
Comments
From past experience debugging WSL issues, my best guess is that this is caused by the storage location of the required files. If they are stored somewhere directly on Windows, stuff gets slow fast. Edit: This is not the case, all configs are properly stored at |
util.root_pattern is called in lots of configs but does not seem to be the cause of this |
Okay, I have found the cause for this. If my PATH contains programs outside WSL, lspconfig is extremely slow. However, if my PATH only contains binaries inside the WSL system, it is quick as normal. Not sure if this should (or can) be addressed by lspconfig or not? |
Thanks for debugging that! Likely caused by nvim-lspconfig/lua/lspconfig/configs.lua Lines 28 to 31 in 94dda50
or maybe there's an ProposalIf you find that dropping the |
@justinmk I've been running with this patch for a few days and this speeds things up nice and snappy for me in WSL: diff --git a/lua/lspconfig/configs.lua b/lua/lspconfig/configs.lua
index b32b8001..3b9967c1 100644
--- a/lua/lspconfig/configs.lua
+++ b/lua/lspconfig/configs.lua
@@ -24,17 +24,6 @@ local configs = {}
--- @field root_dir? string|fun(filename: string, bufnr: number)
--- @field commands? table<string, lspconfig.Config.command>
---- @param cmd any
-local function sanitize_cmd(cmd)
- if cmd and type(cmd) == 'table' and not vim.tbl_isempty(cmd) then
- local original = cmd[1]
- cmd[1] = vim.fn.exepath(cmd[1])
- if #cmd[1] == 0 then
- cmd[1] = original
- end
- end
-end
-
---@param t table
---@param config_name string
---@param config_def table Config definition read from `lspconfig.configs.<name>`.
@@ -64,8 +53,6 @@ function configs.__newindex(t, config_name, config_def)
local config = tbl_deep_extend('keep', user_config, default_config)
- sanitize_cmd(config.cmd)
-
if util.on_setup then
pcall(util.on_setup, config, user_config)
end |
SGTM. Feel free to send a PR. The old lua/lspconfig/ configs are deprecated, but targeted bug fixes are fine. Will plan to tag a release before merging your change. |
@justinmk I am afraid this may have caused some unintended consequences. Basically, all my LSPs have stopped working on both of my Windows machines a few days ago (however, my Linux machine is still working). I’ll use Python as an example: When I open a Python file, I get the following error:
After a short investigation, I found that: :lua print(vim.loop.spawn("lua-language-server.cmd",{})) Output:
Meanwhile: :lua print(vim.loop.spawn("lua-language-server",{})) Output:
So essentially, the At this point, I managed to solve the issue with the following code: require("lspconfig").pyright.setup({
cmd = { 'pyright-langserver.cmd', '--stdio' },
capabilities = capabilities,
}) However, I still wasn’t satisfied and tried to understand why this started happening now. After a bit of binary search on the Git history, I identified the commit 8bb2fac as the one that caused the issue. Reverting So, if it isn’t clear yet, the reason this did not fail before was that the I propose we revert the commit immediately and maybe edit the function so that it is executed only on Windows. I can send you a PR for that if you agree. |
Let's try that. And add a comment explaining why exepath() is there. |
Description
When running my Neovim configuration on WSL, every plugin loads almost as quickly as natively on Linux. However, lspconfig takes almost 2 seconds to require all configs (takes about 20ms on native Linux). Here is the ouput of
nvim --startuptime
:What could be the cause of this? I have tried different Linux distributions on WSL but all of them show this issue..
The text was updated successfully, but these errors were encountered: