Similar experience. Saving whilst not having a go.mod file present grinds to crawl.
I believe this is #56496 related.

Well, I have go.mod files.

Gopls is generally resource hungry on large (or even medium large) workspaces. Furthermore, it is sensitive to which directory you open.

Couple questions:

• Which directory do you open, relative to your go.mod files?
• How many files / packages do you have in your module / workspace?

From that profile, it looks like the typical parsing / typechecking / gc slowness, so I'm not sure there's a solution for you with the current execution model. The issue @renthraysk cited is a known problem related to scanning files, but that doesn't seem to be the cause of what you're experiencing.

@adonovan and I are working to move gopls off of its monolithic build model, which should finally allow us to solve this category of problem.

FWIW, in my experience, this can occur when gopls gets into a bad state. It is responsive (enough) working on a project, it gets unhappy, and then saving fails until you kill and restart it.

For others experiencing this, you can get past it in a pinch by using the VSCode command palette to do "Save without formatting". And then restarting. :/

Hmm, that's... unfortunate.

The likely cause of that is that gopls has loaded a bunch of packages (intermediate test variants) for e.g. a references request, and holds on to them until a restart. This particular behavior will be fixed in the next gopls release.

I had something similar happen last weekend... Gopls was going bonkers taking over cpu on my box while debugging from vscode. I couldn't get back control of the UI and I made the mistake of hard rebooting in the middle (just trying to get my cpu back) which unfortunately bricked my harddrive and OS. I'd had problems with this pet project in the past using gopls. I think it may have had something to do with having a largish bound resource file (but not unreasonable) but that's only a wild guess because I can't repro due to bricking.

I should have waited for 1.20 because I was hoping that might help with this.... But I was eager to do a few things... sigh I accepted the risks of using the latest gopls I guess and knew this was a possibility but up to this point have never seen go involved in anything like this before. It could be that my SSD was on the verge of breaking anyhow and the extra activity pushed it over.

One thing I did notice before it crashed... swap had been triggered and cpu was aggressively trying to swap. I also noticed that gopls seems to leave a bunch of stale folders in /tmp and there were many many in there. Up to this point I had not put effort into managing /tmp.

Oof, sorry about that @joel-rieke

It sounds like there may be something we don't understand going on here, but we are in the process of making major changes to the way gopls executes (https://go.dev/issue/57987), and my hope is that it makes all of these problems go away.

Oof, sorry about that @joel-rieke

It sounds like there may be something we don't understand going on here, but we are in the process of making major changes to the way gopls executes (https://go.dev/issue/57987), and my hope is that it makes all of these problems go away.

No worries, this doesn't change my love of programming in go believe it or not. I'll find my way back. And yes, hopefully the new gopls helps! :)

@bradfitz, do try out gopls@master and tell us what you find. We're close to the v0.12.0 release, which should reduce stable state memory usage by 5-10x for large projects.

@adonovan I still have this problem when I use the master, especially when I copy the code from other places and there are many errors in it, it will be very slow to save only when there are errors

I have similar issue when opening and saving projects with VSCode thru SSH running Arch VM, cpu usage will skyrocket to 100%. Tried opening/saving the same project on the host (Windows) and another VM running Ubuntu, and it works fine. (project is very small with few files) any pointer how to debug this?

Also similar to #51829

Edit: I figured out that the VM only use the E-Core of my CPU (i7 13700k), disabling the E-core for the vm fix it for me

@findleyr This looks like an exact dup of the problems were were debugging yesterday due to VSCode's slow processing of glob patterns consisting of very long comma-separated lists of directories (see #60089 and CL 496186), and perhaps also sequential execution of go mod tidy, and the fact that this is done even when the metadata hasn't changed.
(See also #59176, perhaps another dup.)

@adonovan let's close this after we cut the release candidate containing our fix. Then it will be easy for people to test, and comment if they can still reproduce the freezing.

I am 92% sure this is a dupe, and now fixed.

We have cut gopls@v0.12.0-pre.3, which we believe contains a fix for the specific freezing experienced after save in VS Code.

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

Please comment if you experience otherwise.

I don't want to jinx it, but so far so good! 🤞

Apologies for commenting on a closed issue, but I'm getting this same issue and it's completely crashing my macbook unless I kill the go or gopls process manually.
Loving learning Golang but this issue is a bit frustrating. Thanks in advance for looking at this issue.

Details:
go version go1.21.4 darwin/arm64
M1 Pro 16GB - Ventura 13.6 (22G120)

Hi @joshghent . Could you please open a new issue, filling out the gopls issue template?
https://github.com/golang/go/issues/new/choose

Apologies for commenting on a closed issue, but I'm getting this same issue and it's completely crashing my macbook unless I kill the go or gopls process manually. Loving learning Golang but this issue is a bit frustrating. Thanks in advance for looking at this issue. Is your gopls up to date?

Details: go version go1.21.4 darwin/arm64 M1 Pro 16GB - Ventura 13.6 (22G120)

Bummer... thought this was fixed... On linux it seems fine lately... But haven't tried with latest go1.21.4 -- debugging the same project of mine that caused this behavior.

Is your gopls up to date @joshghent ?

It really should be better now: the code actions operation is now essentially a no-op, except for running goimports, which can sometimes hang (https://go.dev/issue/59216).