Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/tools/gopls: high memory use and sluggishness #45363

Open
bhcleek opened this issue Apr 2, 2021 · 2 comments
Open

x/tools/gopls: high memory use and sluggishness #45363

bhcleek opened this issue Apr 2, 2021 · 2 comments
Assignees
@heschi
Labels
gopls/performance gopls Tools
Milestone
gopls/unplanned

Comments

@bhcleek
Copy link
Contributor

@bhcleek bhcleek commented Apr 2, 2021

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

$ go version
go version go1.16.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

golang.org/x/tools/gopls v0.6.9
    golang.org/x/tools/gopls@v0.6.9 h1:LBBcE2y3Tb4bp79JVLWCQBbvYCFEs5ADGWsQDoSLk1Q=

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

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/Users/bhcleek/go/bin"
GOCACHE="/Users/bhcleek/Library/Caches/go-build"
GOENV="/Users/bhcleek/Library/Application Support/go/env"
GOEXE=""
GOFLAGS="-mod=vendor"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/bhcleek/go/pkg/mod"
GONOPROXY="$INTERNAL_REPOS"
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/bhcleek/go"
GOPRIVATE="$INTERNAL_REPOS"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/bhcleek/src/$MODULE/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/f9/d6g779t53gq_20w0zm2f_1zm0000gn/T/go-build3331311271=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Start up gopls in our monorepo in module aware mode by opening vscode or Vim w/ vim-go

What did you expect to see?

Similar memory use and performance as when using GOPATH mode.

What did you see instead?

Very high memory use and sluggishness. Using module aware mode, gopls very quickly starts using 10GB of memory or more. Other users internally report even higher memory use.

Performance is generally very sluggish. Completion requests, for example, have a noticable delay before a response is delivered.

In GOPATH mode, memory sits around 300MB and gopls is very responsive.
@gopherbot gopherbot added the gopls label Apr 2, 2021
@heschi heschi self-assigned this Apr 3, 2021
@heschi
Copy link
Contributor

@heschi heschi commented Apr 3, 2021

I'm working with @bhcleek on this privately.

@seankhliao seankhliao changed the title gopls: high memory use and sluggishness x/tools/gopls: high memory use and sluggishness Apr 3, 2021
@gopherbot gopherbot added the Tools label Apr 3, 2021
@gopherbot gopherbot added this to the Unreleased milestone Apr 3, 2021
@stamblerre stamblerre removed this from the Unreleased milestone Apr 5, 2021
@stamblerre stamblerre added this to the gopls/unplanned milestone Apr 5, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Apr 19, 2021

Change https://golang.org/cl/310170 mentions this issue: internal/lsp: introduce DegradedLowMemoryMode

gopherbot pushed a commit to golang/tools that referenced this issue Apr 23, 2021
@heschi
internal/lsp: introduce MemoryMode
e435455 
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's time to accept some functionality loss.

DegradeClosed MemoryMode typechecks all packages in ParseExported mode
unless they have a file open. This should dramatically reduce memory
usage in monorepo-style scenarious, where a ton of packages are in the
workspace and the user might plausibly want to edit any of them.
(Otherwise they should consider using directory filters.)

The cost is that features that work across multiple packages...won't.
Find references, for example, will only find uses in open packages or in
the exported declarations of closed packages.

The current implementation is a bit leaky; we keep the ParseFull
packages in memory even once all their files are closed. This is related
to a general failure on our part to drop unused packages from the
snapshot, so I'm not going to try to fix it here.

Updates golang/go#45457, golang/go#45363.

Change-Id: I38b2aeeff81a1118024aed16a3b75e18f17893e2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/310170
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@bcmills bcmills mentioned this issue Jun 23, 2021
Open
@findleyr findleyr mentioned this issue Jul 7, 2021
Closed
@bhcleek bhcleek mentioned this issue Aug 22, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@heschi heschi

Labels
gopls/performance gopls Tools
Projects
None yet
Milestone
gopls/unplanned
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
@bhcleek @stamblerre @gopherbot @heschi @findleyr and others