-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: vet the DegradeClosed memory mode and move out of experimental #46902
Comments
Change https://golang.org/cl/333689 mentions this issue: |
When we open a file in a package, independent of whether it is in the workspace, we type check in ParseFull mode. However, several other code paths don't find this better parse mode. We need a better abstraction, but for now improve a couple code paths specifically for the purpose of fixing Hover content. Updates golang/go#46158 Updates golang/go#46902 Change-Id: I34c0432fdba406d569ea963ab4366336068767a2 Reviewed-on: https://go-review.googlesource.com/c/tools/+/333689 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Change https://golang.org/cl/336410 mentions this issue: |
In my testing, the gopls degraded memory mode (currently set via "memoryMode": "DegradeClosed") did not save as much memory as expected due to still type checking all packages in the workspace (even if in ParseExported mode). It is also annoying to get incomplete results from references and renaming. I think we can (and should) fix both problems: don't even consider packages that aren't 'reachable' via open files, but fully type check the reverse transitive closure of the packages you're working on. This CL does exactly that, by swapping out the concept of 'workspace packages' with 'active packages'. In testing, this decreased my memory footprint while working on std by 3-4x when compared to normal mode, and 2x when compared to the previous implementation of DegradeClosed. It still needs more testing before we move this option out of experimental. For golang/go#46902 Change-Id: I1e319d0b1607d344d27e797ce32de057d7a583f9 Reviewed-on: https://go-review.googlesource.com/c/tools/+/336410 Trust: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Change https://go.dev/cl/472179 mentions this issue: |
I'm not sure we should remove the 'memoryMode' setting yet, until we have more data on the performance of gopls' new architecture. Moving this to v0.13.0. |
Perhaps we can provide users all the control the need with just two parameters to delay the onset of type checking and of go.analysis? |
Should we remove it for v0.15? |
Change https://go.dev/cl/548739 mentions this issue: |
https://golang.org/cl/330529 fixed loading of std and cmd, resulting in better features for std and cmd but worse resource usage.
"memoryMode": "DegradedClosed"
should per my recollection revert us to the old model, but it seems not to work. We should fix this. More generally, I think the degraded memory model could be useful for many users, and we should vet it and move it out of experimental.CC @stamblerre
The text was updated successfully, but these errors were encountered: