x/tools/gopls: excessive invocations of "go mod tidy" #38816
Labels
FrozenDueToAge
gopls
Issues related to the Go language server, gopls.
Tools
This label describes issues relating to any tools in the x/tools repository.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Running gopls from golang/tools@542909f (latest as of writing).
Go 1.14.2; Ubuntu 20.04, amd64.
What did you do?
While working on a Go project whose working directory happened to contain many non-go files (millions of xml files), I discovered that my machine was becoming bogged down by something. In the end I discovered tens of "go mod tidy" processes all competing with each other to stat all of these files. (That cmd/go bug is covered by #38791).
What did you expect to see?
Normal operation of my computer (not progressively slowing down with ever more procesess).
What did you see instead?
CPU spiral of doom, with >30 go mod tidy processes running and the computer becoming progressively more unusable.
Discussion
This highlighted that
go mod tidy
is being run a lot, and it's not always a cheap command. As I understand it, this command will have to read the directory entries of all directories below the Go module it's run on in order to find Go files, and that alone is still quite expensive in my setup, even if #38791 is addressed.@mvdan and @bcmills discussed that gopls may be able in principle to do better at minimizing
go mod tidy
invocations. I think this should be the primary thing which is fixed, since I care about battery life of my laptop.There is another concern here, which is that gopls allowed so many concurrent invocations of go mod tidy which were stuck competing for the same resources. It seems that these should be gated, and some sort of timeout/warning in place if it takes excessively longer than expected.
/cc @stamblerre @ianthehat
The text was updated successfully, but these errors were encountered: