-
Notifications
You must be signed in to change notification settings - Fork 15
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
Startup time optimization #34
Comments
Lazily loading lsp's configs could also allow extensions plugins to be loaded lazily (i'm thinking about SchemaStore for json, fluter tools, omnisharp extended for csharp and so on). Not sure how much that would change startup time tho. |
Something simple like this might have a big effect already: local function setup_servers_for_filetype(filetype)
local servers = filetype_to_servers[filetype] -- this mapping already exists in lazy-lsp.nvim
if servers then
for _, server in ipairs(servers) do
require 'lspconfig'[server].setup {}
end
end
end
vim.api.nvim_create_autocmd("FileType", {
pattern = "*", -- This will trigger the autocommand for any filetype
callback = function(args)
setup_servers_for_filetype(args.match)
end,
}) Thinking about it, the For example: On any open file, have a command to show a selection of available servers, which can be installed using |
This mapping is collected during start by reading all Registering autocmd based on corresponding filetypes to run setups lazily (2.) is now implemented. |
Loading the plugin adds roughly following time penalty (measured on Linux, likely a bit slower on other OSes):
20ms spent inlspconfig.manager
afterwardsFirst optimization would be to reduce 2) by setting up the servers only when a file of a given filetype is opened. This would need figuring out what lspconfig does internally, which events it hooks.done in #31Second optimization would be to reduce 1). We could build up a mapping from filetype to servers so we don't need to load individual configs upfront. The downside is that we would need to update the plugin more often to make sure it tracks the upstream to make sure we don't miss filetypes.
The text was updated successfully, but these errors were encountered: