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: too many memory usage #37759

Closed
tianhongw opened this issue Mar 9, 2020 · 5 comments
Closed

x/tools/gopls: too many memory usage #37759

tianhongw opened this issue Mar 9, 2020 · 5 comments
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.
Milestone
gopls/v0.4.0

Comments

@tianhongw
Copy link

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
Screen Shot 2020-03-09 at 21 59 59

What did you expect to see?

less memory usage instead of 8.53GB

What did you see instead?

Screen Shot 2020-03-09 at 18 58 22

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

Ref: #36943
@gopherbot gopherbot added this to the Unreleased milestone Mar 9, 2020
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Mar 9, 2020
@gopherbot
Copy link

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 stamblerre modified the milestones: Unreleased, gopls/v1.0.0 Mar 9, 2020
@stamblerre
Copy link
Contributor

stamblerre commented Mar 9, 2020 •
edited

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
Copy link
Author

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
Copy link
Contributor

stamblerre commented Mar 11, 2020 •
edited

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

@stamblerre
Copy link
Contributor

Duplicate of #37670

@stamblerre stamblerre marked this as a duplicate of #37670 Mar 11, 2020
@stamblerre stamblerre modified the milestones: gopls/v1.0.0, gopls/v0.4.0 Jul 22, 2020
@golang golang locked and limited conversation to collaborators Jul 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
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.
Projects
None yet
Milestone
gopls/v0.4.0
Development

No branches or pull requests
3 participants
@stamblerre @gopherbot @tianhongw