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

x/tools/gopls: requires tons of memory #30309

Open
mattn opened this issue Feb 19, 2019 · 33 comments

Comments

Projects
None yet
@mattn
Copy link
Member

commented Feb 19, 2019

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

$ go version
go version devel +a10b4cff91 Sun Feb 17 04:46:20 2019 +0000 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\mattn\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\mattn\go
set GOPROXY=
set GORACE=
set GOROOT=C:\go
set GOTMPDIR=
set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\mattn\AppData\Local\Temp\go-build232338458=/tmp/go-build -gno-record-gcc-switches

What did you do?

Install gopls from latest x/tools/cmd/gopls, open daemon.go with vim-lsp.

And send textDocument/completion request from vim-lsp.

What did you expect to see?

In my personal experience, I thought gopls take about 500-800MB memory usage.

What did you see instead?

gopls take 3.5 GB memory usage.

image

@gopherbot gopherbot added this to the Unreleased milestone Feb 19, 2019

@pwaller

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2019

I second this.

Whilst using gopls, I notice a steady increase of memory until it OOMs my system (which has 30GiB spare). I've been using gopls on the go compiler itself, and on the x/tools repository. I regularly have to kill gopls to prevent it from using too much RAM.

@bcmills

This comment has been minimized.

Copy link
Member

commented Feb 28, 2019

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

We are currently working on a number of improvements to gopls, particularly caching, which should solve a lot of these issues. As of right now, gopls calls go/packages.Load on every keystroke, which is likely why it requires so much memory. There should be updates on this soon.

@gopherbot

This comment has been minimized.

Copy link

commented Mar 3, 2019

Change https://golang.org/cl/164779 mentions this issue: internal/lsp: handle initializationOptions

@gopherbot

This comment has been minimized.

Copy link

commented Mar 6, 2019

Change https://golang.org/cl/165438 mentions this issue: internal/lsp: add cache for type information

gopherbot pushed a commit to golang/tools that referenced this issue Mar 8, 2019

internal/lsp: add cache for type information
This change adds an additional cache for type information, which here is
just a *packages.Package for each package. The metadata cache maintains
the import graph, which allows us to easily determine when a package X
(and therefore any other package that imports X) should be invalidated.

Additionally, rather than performing content changes as they happen, we
queue up content changes and apply them the next time that any type
information is requested.

Updates golang/go#30309

Change-Id: Iaf569f641f84ce69b0c0d5bdabbaa85635eeb8bf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/165438
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
@mattn

This comment has been minimized.

Copy link
Member Author

commented Mar 11, 2019

I'm trying latest master branch with same file.

image

memory usage is improved considerably. And completion seems to be faster.

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

Closing for now, we can reopen as needed.

@stamblerre stamblerre closed this Mar 12, 2019

@stamblerre stamblerre added the gopls label Mar 12, 2019

@speedwheel

This comment has been minimized.

Copy link

commented May 9, 2019

Is this normal? I get 7gb usage from gopls.exe

memory

@200sc

This comment has been minimized.

Copy link

commented May 9, 2019

This also happened to me; wasn't actively using vscode at the time:
image

It kept using more memory until the machine was OOM.

@Akumzy

This comment has been minimized.

Copy link

commented May 10, 2019

Also in Ubuntu
Screenshot from 2019-05-10 17-19-08

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

What is the size of the projects that you were working on? gopls caches type information so the larger the project, the more memory it will use. It shouldn't keep using more memory or OOM, however, unless you are consistently adding new dependencies.

@stamblerre stamblerre reopened this May 10, 2019

@speedwheel

This comment has been minimized.

Copy link

commented May 11, 2019

@stamblerre My go.mod has around 70 dependencies.

@Akumzy

This comment has been minimized.

Copy link

commented May 11, 2019

@stamblerre I have about 10 dependencies
I don't if the information below will be helpful
Screenshot from 2019-05-11 16-16-00
Screenshot from 2019-05-11 16-16-00

Screenshot from 2019-05-11 21-12-32
Screenshot from 2019-05-11 21-12-32

go.mod file go 1.12

require (
github.com/Akumzy/ipc v0.0.0-20190428150754-76128748c1e5
github.com/asdine/storm v2.1.2+incompatible
github.com/emersion/go-imap v1.0.0-beta.4
github.com/emersion/go-imap-idle v0.0.0-20180114101550-2af93776db6b
github.com/emersion/go-message v0.9.2
github.com/emersion/go-sasl v0.0.0-20161116183048-7e096a0a6197
github.com/stretchr/testify v1.3.0 // indirect
go.etcd.io/bbolt v1.3.2
golang.org/x/oauth2 v0.0.0-20190402181905-9f3314589c9a
)

go.som file cloud.google.com/go v0.34.0 h1:eOI3/cP2VTU6uZLDYAoic+eyzzB9YyGmJ7eIjl8rOPg= cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= github.com/Akumzy/ipc v0.0.0-20190428150754-76128748c1e5 h1:tiD/RAuIZlj2Dy8f5NUhNdBrH5M0F0xPPVVtU6Scug8= github.com/Akumzy/ipc v0.0.0-20190428150754-76128748c1e5/go.mod h1:KtE0oJxRkmbN0MyDlw/wULkL0ey21TF2SpDOfJ+sJUk= github.com/asdine/storm v2.1.2+incompatible h1:dczuIkyqwY2LrtXPz8ixMrU/OFgZp71kbKTHGrXYt/Q= github.com/asdine/storm v2.1.2+incompatible/go.mod h1:RarYDc9hq1UPLImuiXK3BIWPJLdIygvV3PsInK0FbVQ= github.com/davecgh/go-spew v1.1.0 h1:ZDRjVQ15GmhC3fiQ8ni8+OwkZQO4DARzQgrnXU1Liz8= github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/emersion/go-imap v1.0.0-beta.4 h1:QglkDofK1RhU471SqcHxzRlSuPsCL6YpFc+NR5O6H6Q= github.com/emersion/go-imap v1.0.0-beta.4/go.mod h1:mOPegfAgLVXbhRm1bh2JTX08z2Y3HYmKYpbrKDeAzsQ= github.com/emersion/go-imap-idle v0.0.0-20180114101550-2af93776db6b h1:q4qkNe/W10qFGD3RWd4meQTkD0+Zrz0L4ekMvlptg60= github.com/emersion/go-imap-idle v0.0.0-20180114101550-2af93776db6b/go.mod h1:o14zPKCmEH5WC1vU5SdPoZGgNvQx7zzKSnxPQlobo78= github.com/emersion/go-message v0.9.1/go.mod h1:m3cK90skCWxm5sIMs1sXxly4Tn9Plvcf6eayHZJ1NzM= github.com/emersion/go-message v0.9.2 h1:rJmtGZO1Z71PJDQXbC31EwzlJCsA/8kya6GnebSGp6I= github.com/emersion/go-message v0.9.2/go.mod h1:m3cK90skCWxm5sIMs1sXxly4Tn9Plvcf6eayHZJ1NzM= github.com/emersion/go-sasl v0.0.0-20161116183048-7e096a0a6197 h1:rDJPbyliyym8ZL/Wt71kdolp6yaD4fLIQz638E6JEt0= github.com/emersion/go-sasl v0.0.0-20161116183048-7e096a0a6197/go.mod h1:G/dpzLu16WtQpBfQ/z3LYiYJn3ZhKSGWn83fyoyQe/k= github.com/emersion/go-textwrapper v0.0.0-20160606182133-d0e65e56babe h1:40SWqY0zE3qCi6ZrtTf5OUdNm5lDnGnjRSq9GgmeTrg= github.com/emersion/go-textwrapper v0.0.0-20160606182133-d0e65e56babe/go.mod h1:aqO8z8wPrjkscevZJFVE1wXJrLpC5LtJG7fqLOsPb2U= github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM= github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= github.com/stretchr/testify v1.3.0 h1:TivCn/peBQ7UY8ooIcPgZFpTNSz0Q2U6UrFlUfqbe0Q= github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI= go.etcd.io/bbolt v1.3.2 h1:Z/90sZLPOeCy2PwprqkFa25PdkusRzaj9P8zm/KNyvk= go.etcd.io/bbolt v1.3.2/go.mod h1:IbVyRI1SCnLcuJnV2u8VeU0CEYM7e686BmAb1XKL+uU= golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e h1:bRhVy7zSSasaqNksaRZiA5EEI+Ei4I1nO5Jh72wfHlg= golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= golang.org/x/oauth2 v0.0.0-20190402181905-9f3314589c9a h1:tImsplftrFpALCYumobsd0K86vlAs/eXGFms2txfJfA= golang.org/x/oauth2 v0.0.0-20190402181905-9f3314589c9a/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/text v0.3.0 h1:g61tztE5qeGQ89tm6NTjjM9VPIm088od1l6aSorWRWg= golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
@200sc

This comment has been minimized.

Copy link

commented May 12, 2019

I had a few projects with modules open with ~70 dependencies between them.

@WoLfulus

This comment has been minimized.

Copy link

commented May 12, 2019

I have around 10 dependencies and memory goes up to 1GB right away

@Dolmant

This comment has been minimized.

Copy link

commented May 29, 2019

I have experienced similar issues for what it is worth, ubuntu works flawlessly running with <1gb ram but initially running in windows quickly ate all available ram rendering gopls inoperative. Recent updates have improved this significantly, now gopls will only use ~5gb with ~40 dependencies for a single project.

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented May 29, 2019

We have a few pending changes that will hopefully improve the memory consumption - I will update this issue once these changes are submitted.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 1, 2019

Change https://golang.org/cl/178719 mentions this issue: internal/lsp: trim ASTs for which we do not require function bodies

gopherbot pushed a commit to golang/tools that referenced this issue Jun 3, 2019

internal/lsp: trim ASTs for which we do not require function bodies
This change trims the function bodies from the ASTs of files belonging to
dependency packages. In these cases, we do not necessarily need full
file ASTs, so it's not necessary to store the function bodies in memory.

This change will reduce memory usage. However, it will also slow down
the case of a user opening a file in a dependency package, as we will
have to re-typecheck the file to get the full AST. Hopefully, this
increase in latency will not be significant, as we will only need to
re-typecheck a single package (all the dependencies should be cached).

Updates golang/go#30309

Change-Id: I7871ae44499c851d1097087bd9d3567bb27db691
Reviewed-on: https://go-review.googlesource.com/c/tools/+/178719
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
@stamblerre

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2019

The change above was the first of these planned improvements. It would be really helpful to get feedback on it. Did memory consumption decrease for anyone on this thread?

@rvolosatovs rvolosatovs referenced this issue Jun 5, 2019

Merged

gotools: 2019-05-24 -> 2019-06-03 #62725

3 of 10 tasks complete
@Akumzy

This comment has been minimized.

Copy link

commented Jun 5, 2019

I switch to Windows from Linux (Ubuntu) recently and I haven't notice any lag since then

@rvolosatovs

This comment has been minimized.

Copy link

commented Jun 5, 2019

The first "go to definition" on golang/tools@8aaa148 made my NixOS system unresponsive for ~5 minutes(freezes like this are very common with gopls in my experience and have never happened before on the system).

@gopherbot

This comment has been minimized.

Copy link

commented Jun 5, 2019

Change https://golang.org/cl/180857 mentions this issue: internal/lsp: call the trimAST function, actually

@linguohua

This comment has been minimized.

Copy link

commented Jun 6, 2019

@stamblerre
Hi, I test gopls with my project, both on windows7 and ubuntu with vscode, and the result is the same: gopls takes too much memory and cpu.
windows 7 x64:
image
ubuntu 18 x64:
image
my vscode config:
image
my project go.mod:
image

@Dolmant

This comment has been minimized.

Copy link

commented Jun 6, 2019

I have also seen no improvement

@methane

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

@linguohua @Dolmant As far as this comment, the improvement is implemented, but not used yet.

rvolosatovs added a commit to rvolosatovs/tools that referenced this issue Jun 7, 2019

internal/lsp: call the trimAST function, actually
Turns out that when you add a function, it is useful to actually
call it. Looks like I deleted this when merging parts of CL 178719.

This change also modifies the original change to correctly invalidate
the cache when we have to go from a trimmed to untrimmed AST.

Updates golang/go#30309

Change-Id: I6b89d1d2140d77517616cb3956721a157c25ab71
@linguohua

This comment has been minimized.

Copy link

commented Jun 7, 2019

@rvolosatovs @methane Hi, I have test gopls of rvolosatovs's fork, the memory used has decrease from 7G to 5G, it looks good. But the cpu is always so high, 40% of my pc, it never goes down until I close vscode.
image
I guess gopls has fall into some infinite loop, cause it will never response to any request from vscode:
image

pprof cpu:
image

pprof heap:
image

If I add the following code to gopls's main.go:
image
and comment out the call to func "shortestEditSequence" in diff.go:
image
then, the gopls seems to work, maybe leaks some feature, but it now can response to vscode, 'hover', 'go to def', 'auto complete' response quickly. It use 1G memory, cpu is low:
image

now I know by comment out the 'shortestEditSequence' will kill format feature, so i just limit the size of array, in diff.go:
image
now it works fine except files which lines count exceed 1000. So, maybe the 'shortestEditSequence' need a new algorithm to increase performance.

gopherbot pushed a commit to golang/tools that referenced this issue Jun 7, 2019

internal/lsp: fix some issues with trimming ASTs
This change correctly invalidates the cache when we
have to go from a trimmed to untrimmed AST.

The "ignoreFuncBodies" behavior is still disabled due to a racy test.

Updates golang/go#30309

Change-Id: I6b89d1d2140d77517616cb3956721a157c25ab71
Reviewed-on: https://go-review.googlesource.com/c/tools/+/180857
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
@stamblerre

This comment has been minimized.

Copy link
Contributor

commented Jun 10, 2019

@linguohua: Thanks for the detailed report. Do you have "files.eol": "\n" configured in VSCode? I wonder if your formatting is causing problems because gofmt always uses \n line endings, even on Windows.

Also, my apologies re: the change above. It had some bugs, and it's now actually merged. It seems to have decreased memory usage for me, so I hope others will see the same results.

@linguohua

This comment has been minimized.

Copy link

commented Jun 11, 2019

@stamblerre Thanks for your reply. I update to the latest gopls, now it works perfect, the memory is so so so low, only 300M, compare to prev's 7G, the same project, the same vscode config, the same vscode-go, this is so unbelievable, I just can't understand why.

There must be some magic change happend in these commits:
image

Anyway, gopls works great for me now, thanks to all contributors.

@Dolmant

This comment has been minimized.

Copy link

commented Jun 11, 2019

@stamblerre Thanks, I fired up windows to check and it has definitely improved a lot! My same project is now capping out at 3.5GB (from 10+GB) and is usable.

Much appreciated!

@1522784

This comment has been minimized.

Copy link

commented Jun 18, 2019

Before the latest update it needed like 1 or 2 GB more and reached the peak faster. There is a visible improvement, but I don't think this is ideal yet. gopls still requires a lot of space and is very slow overall.
Screenshot (28)

@stamblerre

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

@1522784: We are working on further improvements to help with memory usage, but I would be interested to hear more about the speed issues you are encountering. Would you be willing to share your gopls logs so I can look at the latencies? They can be found by going to View: Debug Console -> Output -> Tasks -> gopls.

@linguohua

This comment has been minimized.

Copy link

commented Jun 20, 2019

@1522784 , Hi, maybe you can provide a heap snapshot to @stamblerre use the following steps:

  1. in the user setting of vscode, paste the following json statements:
    "go.languageServerFlags": [
        "-debug=localhost:8090",
    ],
  1. reload your project, wait the gopls to startup, then go to browser and type "http://localhost:8090/", you will see a web page like this one:
    image

  2. click the 'debug' link, then click 'profiling', and click 'heap', then you can see something like this:
    image

maybe these information can provide some help to gopls contributors.

@jackielii

This comment has been minimized.

Copy link

commented Jul 1, 2019

using latest build 2019-06-28

"debug->profile->heap" just after start up:

heap profile: 1: 32 [1: 32] @ heap/1048576
1: 32 [1: 32] @ 0x7cb496 0x7cb414 0x7caa95 0x7c9a15 0x7e7283 0x8ffb65 0x91a510 0x430858 0x45d841
#	0x7cb495	text/template/parse.(*ListNode).append+0x445			/usr/local/go/src/text/template/parse/node.go:89
#	0x7cb413	text/template/parse.(*Tree).parse+0x3c3				/usr/local/go/src/text/template/parse/parse.go:295
#	0x7caa94	text/template/parse.(*Tree).Parse+0x214				/usr/local/go/src/text/template/parse/parse.go:230
#	0x7c9a14	text/template/parse.Parse+0x124					/usr/local/go/src/text/template/parse/parse.go:55
#	0x7e7282	text/template.(*Template).Parse+0x112				/usr/local/go/src/text/template/template.go:196
#	0x8ffb64	html/template.(*Template).Parse+0x84				/usr/local/go/src/html/template/template.go:189
#	0x91a50f	golang.org/x/tools/internal/lsp/debug.init.ializers+0x1af	/home/jackieli/gomod/saibing-tools/internal/lsp/debug/serve.go:306
#	0x430857	runtime.main+0x1c7						/usr/local/go/src/runtime/proc.go:188


# runtime.MemStats
# Alloc = 1295552
# TotalAlloc = 1295552
# Sys = 71893240
# Lookups = 0
# Mallocs = 6913
# Frees = 211
# HeapAlloc = 1295552
# HeapSys = 66781184
# HeapIdle = 64462848
# HeapInuse = 2318336
# HeapReleased = 0
# HeapObjects = 6702
# Stack = 327680 / 327680
# MSpan = 29088 / 32768
# MCache = 13888 / 16384
# BuckHashSys = 1443399
# GCSys = 2240512
# OtherSys = 1051313
# NextGC = 4473924
# LastGC = 0
# PauseNs = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
# PauseEnd = [0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
# NumGC = 0
# NumForcedGC = 0
# GCCPUFraction = 0
# DebugGC = false

heap after some jumping around
heap.txt

go.mod:

require (
	github.com/RichardKnop/machinery v1.6.5
	github.com/coreos/go-oidc v2.0.0+incompatible
	github.com/gogo/protobuf v1.2.1
	github.com/golang/protobuf v1.3.1 // indirect
	github.com/grpc-ecosystem/go-grpc-middleware v1.0.0
	github.com/hashicorp/golang-lru v0.5.1
	github.com/inconshreveable/mousetrap v1.0.0 // indirect
	github.com/jackielii/process v0.0.0-20190625104948-ee2b034387b8
	github.com/konsorten/go-windows-terminal-sequences v1.0.2 // indirect
	github.com/minio/minio-go/v6 v6.0.29
	github.com/mitchellh/go-homedir v1.1.0
	github.com/pebbe/go-proj-4 v0.9.1
	github.com/pkg/errors v0.8.1
	github.com/pquerna/cachecontrol v0.0.0-20180517163645-1555304b9b35 // indirect
	github.com/sirupsen/logrus v1.4.2
	github.com/spf13/cobra v0.0.3
	github.com/spf13/viper v1.3.1
	github.com/stretchr/testify v1.3.0
	github.com/twpayne/go-geom v1.0.5-0.20190320002942-31a8a3d5e136
	golang.org/x/net v0.0.0-20190522155817-f3200d17e092
	google.golang.org/grpc v1.19.1
	gopkg.in/square/go-jose.v2 v2.3.1 // indirect
)

@stamblerre stamblerre changed the title x/tools/cmd/gopls: requires tons of memory x/tools/gopls: requires tons of memory Jul 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.