/ go Public
x/tools/gopls: bug - loading packages startup penalty occurs for each session with remote gopls server. #51040
Issues related to gopls performance (CPU, memory, etc).
Issues related to the Go language server, gopls.
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
This label describes issues relating to any tools in the x/tools repository.
My goal is to reduce the startup penalty when opening my editor (vim) for a large golang project.
An example is kubernetes. It takes 80 seconds for the "Loading packages" stage to finish. I like to open and close my editor as needed. This means each time I open my editor I might have to wait a considerable amount of time before I can explore the code.
I tried to run gopls in the background using
gopls -listen 127.0.0.1:8118and configuring my editor (nvim w/ coc) to execute
gopls -remote 127.0.0.1:8118. LSP functionality works, but each time I open the editor I have the same loading penalty. This means there's no benefit to running gopls in the background.
My coc-ssettings.json config.
Log message I see:
It might seem that the
gopls -remotecommand is the problem, but I've done some testing to show that's not the case. I created a small test program which reads/writes back and forth from stdin/stdout to a TCP connection with the
gopls -address 127.0.0.1:8118server.
I compiled this program and configured my editor to invoke it when loading the LSP for go code. Again, the LSP functionality works, so the connection is good. However, the loading packages penalty persists, meaning this is in fact happening server-side for each session I make.
The text was updated successfully, but these errors were encountered: