x/tools/gopls: too many memory usage

[tianhongw]

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

$ go version
go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?

Yes

$ gopls version
golang.org/x/tools/gopls v0.3.3
    golang.org/x/tools/gopls@v0.3.3 h1:mTFqRDJQmpSsgDDWvbtGnSva1z9uX2XcDszSWa6DhBQ=

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

go env Output

$ go env

GO111MODULE="auto"
GOARCH="amd64"
GOBIN="/Users/wutianhong/go/bin"
GOCACHE="/Users/wutianhong/Library/Caches/go-build"
GOENV="/Users/wutianhong/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/wutianhong/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/dj/qmfvb5s5595grm_pn25n40100000gn/T/go-build406632642=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

• os: MacOs 10.14.6
• editor: Emacs 26.3
• go project: a large project with 12k+ go files

emacs config

What did you expect to see?

less memory usage instead of 8.53GB

What did you see instead?

heap profile
pprof.alloc_objects.alloc_space.inuse_objects.inuse_space.001.pb.gz

Ref: #36943

[gopherbot]

Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here.

[stamblerre]

Thanks for reporting this issue and for providing the heap profile! I took a look at it, and this seems to be the same issue as #37670. Unfortunately, my response is the same as @heschik's in the issue (#37670 (comment)):

Thanks.

Unfortunately I don't have good news for you. Everything you've posted points to expected behavior -- I don't see any signs of a memory leak or work pileup. It looks like the monorepo is simply too large to work with all at once.

If you're only interested in one folder, you can start VS Code in that folder. If you're interested in multiple, you can add them piecemeal to your workspace, but note that most gopls features, e.g. find references, will only work within one folder.

We'll work on an approach for improving this in gopls/v1.0.0.

[tianhongw]

Thanks for reporting this issue and for providing the heap profile! I took a look at it, and this seems to be the same issue as #37670. Unfortunately, my response is the same as @heschik's in the issue (#37670 (comment)):

Thanks.
Unfortunately I don't have good news for you. Everything you've posted points to expected behavior -- I don't see any signs of a memory leak or work pileup. It looks like the monorepo is simply too large to work with all at once.
If you're only interested in one folder, you can start VS Code in that folder. If you're interested in multiple, you can add them piecemeal to your workspace, but note that most gopls features, e.g. find references, will only work within one folder.

We'll work on an approach for improving this in gopls/v1.0.0.

Thanks for your reply! Should i keep this issue open?

[stamblerre]

Thanks for following up. I think this issue can be closed and marked as a duplicate of #37670.

[stamblerre]

Duplicate of #37670