x/tools/gopls: Request to decrease or make configurable background import refresh frequency #44701
Comments
gopherbot
added
Tools
|
It sounds likely that there is a different issue happening here, since |
stamblerre
added
the
WaitingForInfo
|
@stamblerre Attaching my logs below, but would love if you could clarify why you don't believe the background imports cache refresh is the issue though please. I have consistently seen that new packages appear to be not recognized by the LSP until the background imports refresh completes. I will close buffers, write files, etc., but not until the instant whenever the refresh process completes (I follow gopls logs up side-by-side) do I receive my newly-created package in say, my list of completions for using a variable in that package for instance (this example is the primary issue I'm having with it). I am uncertain of what triggers the actual refresh process to kick off in the first place, so I suspect perhaps your better knowledge of that is why you believe it is not causing an issue? Also fwiw regarding the timings I observed of those background imports refreshing processes: it appears that it consistently takes a few seconds (~10-15) on its first run sometime after the server first starts up then each subsequent refresh takes around ~1-2 seconds. These are again, my observations from creating simple go modules projects from scratch and adding one or two new packages each with one new struct in them. LSP logs2021/03/02 16:52:50 go env for $HOME/workspace/gopls-wat-do (root $HOME/workspace/gopls-wat-do) (go version go version go1.15.6 darwin/amd64) (valid build configuration = true) (build flags: []) GOPROXY=https://proxy.golang.org,direct GOMODCACHE=$HOME/go/pkg/mod GONOPROXY= GONOSUMDB= GO111MODULE= GOFLAGS= GOINSECURE= GOMOD=$HOME/workspace/gopls-wat-do/go.mod GOSUMDB=sum.golang.org GOPRIVATE= GOROOT=/usr/local/Cellar/go/1.15.6/libexec GOCACHE=$HOME/Library/Caches/go-build GOPATH=$HOME/go |
The background imports refresh is only used by the import organization logic, and based on your first description, it seemed like the issue was with diagnostics:
When you mention completion above, are you referring to completions for a package you have already imported into your program or a package that has not yet been imported? A repro case would be best here. It also looks like those logs are not verbose--is there a way for you to add |
|
Thank you for clarifying re: background imports refresh.
The latter: fails to provide completion for a package which was just created, but yet to be imported in the current file. Repro that I've been doing looks something like this:
Not quite certain myself either haha, but I will try to figure it out and attach them here/a separate comment when I get the time. Just wanted to respond since it had been a few days and didn't want this going stale. |
|
Combating Sunday scaries a bit strangely here with this late debugging, but figured out how to increase the logging level with I noticed that doing my above repro actually worked as expected: my package was suggested as a completion almost immediately multiple times (not always, but maybe we can just gloss over those for now). I decided to try and carry on with the project I was originally working in which I was creating a new package called Modified the original repo above to instead:
I noticed in the logs (attached below) pretty much always saw a In which case I'm wondering if it's intentional or not that Logs: https://gist.github.com/jspawar/538af493d62f8d9d8b659933c0799983 |
|
I tried reproducing this and noticed that it would take a couple of seconds before the imports cache refreshed, at which point
The isIncomplete setting is unrelated--it is set so that the editor client continues requesting completion results as you type more characters. |
|
Closing as there hasn't been any activity on this in some time. |
What version of Go are you using (
go version)?$ go version go version go1.15.6 darwin/amd64 $ gopls version golang.org/x/tools/gopls v0.6.6 golang.org/x/tools/gopls@v0.6.6 h1:GmCsAKZMEb1BD1BTWnQrMyx4FmNThlEsmuFiJbLBXio=Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Have been using gopls with emacs (via lsp-mode) and noticed that even with a brand new golang project using go modules, it was incredibly slow to get the LSP to recognize any new packages I'd create. There were multiple instances where I observed that it took minutes (~5-15) for the LSP to recognize that a new struct I'd made in a new package existed, albeit providing logs of the following form immediately on package creation:
These appeared to indicate to me that gopls knew my packages existed, as well as their source files which contained my new structs I wanted to interact through the LSP with (e.g. completions). However, it reality they remained unknown until I saw logs of the form
background refresh finished after Xs.Digging into it more, it appears that this background refresh process scans either the entire gopath or the go module from its root then doesn't try again for
50 x (however long that took)seconds: https://github.com/golang/tools/blob/f5a4005dda57a682af872b31ea2ae6999aa44971/internal/lsp/cache/imports.go#L117More often than not, I observed this taking only 1-3 seconds (which is still concerningly slow for a brand new go project with only two source code files) in turn meaning that the next refresh wouldn't happen for 1-2 minutes. There was a not insignificant number of times it took even longer, like say 10-20 seconds (not sure why) which in turn meant it wouldn't refresh again for another 10-15 minutes which is far too long.
I don't quite entirely understand the intention behind that frequency calculation; regardless though, it seems like something that should be configurable for those of us who are content to do that tuning ourselves. At the very least, we should decrease the frequency because it seems like a very unnecessarily large backoff.
What did you expect to see?
Background import refresh happening at a reasonable frequency on the order of seconds (< minute)
What did you see instead?
Background import refresh happening at an unreasonable frequency on the order of minutes
The text was updated successfully, but these errors were encountered: