x/tools/gopls: poor performance and crash on google-cloud-go

[codyoss]

gopls version: v0.12.0-pre.1 (go1.20.3)
gopls flags:
update flags: proxy
extension version: 0.38.0
go version: 1.20.3
environment: Visual Studio Code darwin
initialization error: undefined
issue timestamp: Tue, 09 May 2023 14:45:46 GMT
restart history:
Tue, 09 May 2023 14:43:43 GMT: activation (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

gopls crashed while in google-cloud-go. I believe I was searching to open a file before this happened.

Please attach the stack trace from the crash.
A window with the error message should have popped up in the lower half of your screen.
Please copy the stack trace and error messages from that window and paste it in this issue.

https://gist.github.com/codyoss/f19310e0db7499861e7f3d92ad056625

Failed to auto-collect gopls trace: unrecognized crash pattern.

Also got the following message post crash: extension-output-golang.go-#3-gopls (server): tokenization, wrapping and folding have been turned off for this large file in order to reduce memory usage and avoid freezing or crashing. and Connection to server got closed. Server will not be restarted.

[codyoss]

Editor and computer came pretty unusable post crash. Downgrading for now to make things better again. We recently added a go.work to this repository which I think makes gopls maybe try to do too much extra work. On the previous version(0.11.X) I noticed things were better since I did not need to open editor at sub-module roots -- but the perf is starting to make me think it is not worth the tradeoff of having a go.work file. I think this is a great repo to test out gopls/go.work in because it has so many modules and so much code :)

[findleyr]

Thanks Cody.

It looks like the critical top portion of your crash is cut-off. Do you still have it?

[codyoss]

Apologies, I assumed select all would have selected all 😿 I no longer do. I will see if I can reproduce it later today if I have a couple of minutes.

[codyoss]

Tried for a couple to make it crash again but was unable to. The experience in the pre version does seem noticeably slower than 0.11.0 for this repo though.

• I noticed jumping to a reference to take several seconds consistently after jumping around a bit.
• I was unable to open files from the file explorer of vscode after some time, but could if I searched them with cmd + P.
• In the file explorer I also noticed it need time to load the filesystem a few times -- opening a folder with one file in it took several seconds to load the contents of the folder.
• Got the spinning ball of death a few times on my mac

If there is nothing actionable from the report feel free to close, I don't think I can keep the version installed to try to reproduce though as it affects my daily dev too much.

More info on the type of machine I am on:
Chip: m1 pro
OS: MacOS 13.3.1
Memory: 16GB

[findleyr]

@codyoss if it's too slow for your daily dev, that's actionable.

I'll take a look.

[findleyr]

Well, it's not that bad for me (I suspect due to the linux filesystem). Using coc.nvim, performs about the same as v0.11.0 and uses ~1/6th of the memory. I am sure that there is a problem here, it just doesn't yet reproduce in my environment.

However, I grabbed a profile while editing this repo interactively, and the results are astonishing: top -cum lists typeCheckImpl as constituting 2.8% of CPU. Meanwhile, snapshot.IgnoredFile constitutes 48% of CPU(!), due to the expense of span.URIFromPath. IgnoredFile is extremely inefficient, as it is O(files*modules), and this repo contains 144 modules. This should be easy to fix.

So, the good news is that there is some very low hanging fruit here. The bad new is that I think this fruit exists in v0.11.0 as well, and I don't yet understand the regression.

I think making gopls work well on this repository could be a good exercise before the second prerelease, as it has so many workspace modules.

Moving this issue to the Go issue tracker, since it is (probably) a gopls issue.

CC @adonovan