go: x/tools/gopls: high memory consumption

What version of Go are you using (`go version`)?

$ go version
go version go1.16.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

Ubuntu 20.04.2 LTS

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mauclair/.cache/go-build"
GOENV="/home/mauclair/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/mauclair/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/mauclair/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.16.2"
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=/home/mauclair/tmp/go-build3185508688=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Using emacs with lsp-mode + gopls, gopls used 10GiB memory (if it’s helpful, this is is a monorepo with a high volume of generated gRPC code)

What did you expect to see?

Lower memory consumption

What did you see instead?

10GiB memory consumed

Attached gopls memory profile

gopls.1480857-10GiB-nonames.zip

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 38 (14 by maintainers)

Commits related to this issue

internal/lsp/cache: remove type info trimming This broke staticcheck and x/tools/refactor, most notably used for our rename support. Doesn't look like a winner. Roll it back :( Updates golang/go#454... — committed to golang/tools by heschi 3 years ago
internal/lsp: introduce MemoryMode We still hear from users for whom gopls uses too much memory. My efforts to reduce memory usage while maintaining functionality are proving fruitless, so perhaps it... — committed to golang/tools by heschi 3 years ago

Most upvoted comments

Thanks. As noted in #61178, the profile definitely indicates that the majority of allocation is related to staticcheck.

Now that we have an approximate cause, let’s continue discussion on that issue. My guess is that we will be able to reproduce, by enabling staticcheck with some repositories we know to be similarly problematic for analysis.

findleyr on Jul 6, 2023

Thanks! We’ve updated to 0.12.0 and are seeing roughly the order-of-magnitude decrease in memory footprint reported in the release notes

mikeauclair on May 30, 2023