go: x/tools/gopls: high memory consumption
What version of Go are you using (go version)?
$ go version go version go1.17 linux/amd64
Does this issue reproduce with the latest release?
Yes. I have the latest versions of gopls and go.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/mikhail/.cache/go-build" GOENV="/home/mikhail/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/mikhail/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/mikhail/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.17" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4125386380=/tmp/go-build -gno-record-gcc-switches"
What did you do?
Opened cockroachDB repository in vim(same thing with neovim) with vim-go plugin and gopls enabled. I’ve removed everything but vim-go and gopls from the .vimrc and disabled all other plugins. But the result is the same.
What did you expect to see?
Normal memory consumption. For example, Jetbrains Goland uses ~2GB when this project is open
What did you see instead?
gopls consumes about 9GB of memory, sometimes more than 14GB.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 33
- Comments: 16 (8 by maintainers)
The next release of gopls (expected in March) will include major reductions in memory usage, so if you’re on the verge of giving up, consider holding on just a few more weeks.
Hi folks,
We just released the second prerelease, which fixes several bugs reported since
-pre.1and smooths out performance a bit:At this point, gopls’ memory footprint has fundamentally changed: gopls requires very little data in memory other than file content. To reduce its steady-state memory further would require dropping file content, and we don’t current plan to do that (doing so would introduce a lot of complexity). There may be additional issues related to memory: for example, gopls could use less memory during large operations such as rename. However, those would be specific problems that deserve a separate github issue.
Therefore, I am going to close this issue as fixed. Thanks everyone for your feedback and patience.
Hi all, we just cut the first prerelease version of gopls to include the new architecture:
More details in the release notes.
This is a prerelease version: there are several known regressions that we’re still working on. However, it should use significantly less memory. I’d love to hear from users currently struggling with gopls’ memory usage, whether this release improves their experience. If it doesn’t, there may be more we can do given additional details.
Thanks!
I’d say the high memory usage is expected currently - Goland and gopls take different approaches.
Gopls dev team is currently working on improvement in this area. The
"DegradeClosed"memory mode @heschi shared is one of the directions we are exploring. Please give it a try (warning: still experimental). Feedback and bug reports for the DegradeClosed mode are greatly appreciated!Early impressions are very positive for me: Working with the Gitea codebase in VSCode, after letting things settle, my
goplsRSS has almost halved, from 1,044,976 to 568,124, and in the time it’s taken me to write this has somehow fallen further to 478,228. You’ve made a cranky old infra engineer very happy, thank you all very much! 💙I thought all source needs to be in /src directory - it means hundreds of imports and all my projects! Happy if someone can explains how to remove this “virus” from VS Code.
It’s great to hear that. Because right now my gopls is using 34 Gb of memory 😃