In general gopls can be fairly memory hungry on large projects. This is an ongoing area of research. cc @findleyr.

FWIW, glancing at the attached zip, github.com/cockroachdb/cockroach/pkg/workload/geospatial is probably costing you 500+ MB all by itself. That package contains a very large composite literal that is very expensive to parse and type check. Removing that composite literal from gopls' scope, perhaps by changing its representation or excluding it from the build with a build tag, might be well worth the effort.

@heschi I've added a new archive. Please take a look at it.
gopls consumes more memory during use.
Isn't there any memory leak?

No. I don't see any signs of a memory leak.

If you want, you can try setting https://github.com/golang/tools/blob/master/gopls/doc/settings.md#memorymode-enum. Use it at your own risk.

So this is normal behavior?
Why is there such a big difference in memory consumption compared to JB Goland?

I'd say the high memory usage is expected currently - Goland and gopls take different approaches.

Gopls dev team is currently working on improvement in this area. The "DegradeClosed" memory mode @heschi shared is one of the directions we are exploring. Please give it a try (warning: still experimental). Feedback and bug reports for the DegradeClosed mode are greatly appreciated!

In general gopls can be fairly memory hungry on large projects.

I thought all source needs to be in /src directory - it means hundreds of imports and all my projects! Happy if someone can explains how to remove this "virus" from VS Code.

How to enable "DegradeClosed" memory mode in vim?

I'd say the high memory usage is expected currently - Goland and gopls take different approaches.

Gopls dev team is currently working on improvement in this area. The "DegradeClosed" memory mode @heschi shared is one of the directions we are exploring. Please give it a try (warning: still experimental). Feedback and bug reports for the DegradeClosed mode are greatly appreciated!

The next release of gopls (expected in March) will include major reductions in memory usage, so if you're on the verge of giving up, consider holding on just a few more weeks.

@n-r-w which version of gopls are you using?

We're still smoothing out some edge cases and so have not yet cut a prerelease for gopls@v0.12.0, but I expect memory usage to be significantly reduced once we do.

@n-r-w which version of gopls are you using?

v0.11.0

We're still smoothing out some edge cases and so have not yet cut a prerelease for gopls@v0.12.0, but I expect memory usage to be significantly reduced once we do.

It's great to hear that. Because right now my gopls is using 34 Gb of memory :)

Hi all, we just cut the first prerelease version of gopls to include the new architecture:

go install golang.org/x/tools/gopls@v0.12.0-pre.1

More details in the release notes.

This is a prerelease version: there are several known regressions that we're still working on. However, it should use significantly less memory. I'd love to hear from users currently struggling with gopls' memory usage, whether this release improves their experience. If it doesn't, there may be more we can do given additional details.

Thanks!

Early impressions are very positive for me: Working with the Gitea codebase in VSCode, after letting things settle, my gopls RSS has almost halved, from 1,044,976 to 568,124, and in the time it's taken me to write this has somehow fallen further to 478,228. You've made a cranky old infra engineer very happy, thank you all very much! 💙

Thanks for the feedback, @garymoon!

in the time it's taken me to write this has somehow fallen further to 478,228

FWIW this is likely due to a background GC cycle, and/or the timing of background work that gopls is doing. To get a more detailed picture of memory usage, you can start gopls with -debug=localhost:8080 and visit http://localhost:8080/memory.

Hi folks,

We just released the second prerelease, which fixes several bugs reported since -pre.1 and smooths out performance a bit:

go install golang.org/x/tools/gopls@v0.12.0-pre.2

At this point, gopls' memory footprint has fundamentally changed: gopls requires very little data in memory other than file content. To reduce its steady-state memory further would require dropping file content, and we don't current plan to do that (doing so would introduce a lot of complexity). There may be additional issues related to memory: for example, gopls could use less memory during large operations such as rename. However, those would be specific problems that deserve a separate github issue.

Therefore, I am going to close this issue as fixed. Thanks everyone for your feedback and patience.