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: saving is very slow with the latest update #45092

Closed
evanw opened this issue Mar 17, 2021 · 7 comments
Closed

x/tools/gopls: saving is very slow with the latest update #45092

evanw opened this issue Mar 17, 2021 · 7 comments

Comments

@evanw
Copy link

@evanw evanw commented Mar 17, 2021

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

$ go version
go version go1.16.2 darwin/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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/evan/Library/Caches/go-build"
GOENV="/Users/evan/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/evan/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/evan/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.2"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/evan/dev/esbuild/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/j6/np400cw17sz0n5ljd67byrzw0000gn/T/go-build1589752302=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I use the Go extension in Visual Studio Code (v0.23.2) which uses gopls (v0.6.7) on a project with a single dependency.

What did you expect to see?

The Go extension formats code and automatically inserts missing imports whenever I save. I expect this to feel instant, and it has been instant in the past.

What did you see instead?

Something changed recently. Now saving a Go file takes a really long time (e.g. 7 seconds) and causes Visual Studio Code to show a Saving 'resolver.go': Getting code actions from ''Go'' (configure). message in the corner. This is really breaking my flow because it means I constantly have to wait in between adjusting code and trying it out.

I would love for this to be fixed of course, but I would also love to have a workaround in the meantime. For example, I assume this is due to automatic import insertion and not due to code formatting. Is there a way I can disable the slow part but just keep code formatting on save? Maybe there is some cache somewhere that has gotten filled up and can be cleared to make this go faster?

@gopherbot gopherbot added this to the Unreleased milestone Mar 17, 2021
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Mar 17, 2021

Can you please share your gopls logs? Information on how to capture them can be found here.

@stamblerre stamblerre changed the title x/tools/gopls: Saving is very slow with the latest update x/tools/gopls: saving is very slow with the latest update Mar 17, 2021
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v0.6.8 Mar 17, 2021
@evanw
Copy link
Author

@evanw evanw commented Mar 18, 2021

Here's a log capture: gopls-slow-save.log. This is the result of clearing the log, changing the indentation of a single line, re-saving the file, and waiting for the file to be saved. This particular save operation took around around 23 seconds to complete.

I do have a lot of files under the top-level project directory in case that's what's causing this. The count from find . | wc -l in the top-level project directory is 351,777 files and directories. This is because I'm writing a JavaScript bundler and there are some projects I use for testing with node_modules directories. These test projects are all under .gitignore however.

Edit: And the Go-specific lines of my Visual Studio Code settings.json file are these:

    "go.lintOnSave": "off",
    "go.vetOnSave": "off",
    "go.formatTool": "goimports",
    "go.languageServerFlags": [
        "-rpc.trace"
    ],
    "[go]": {
        "editor.insertSpaces": false,
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        }
    },
@SimonRichardson
Copy link

@SimonRichardson SimonRichardson commented Mar 18, 2021

Also experiencing the same issue with a large codebase[1]

  1. https://github.com/juju/juju

I'm currently attempting to downgrade gopls to identify when the slowdown was introduced.

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 18, 2021

Change https://golang.org/cl/303149 mentions this issue: internal/lsp: remove module diagnostics from code actions

@gopherbot
Copy link

@gopherbot gopherbot commented Mar 18, 2021

Change https://golang.org/cl/303150 mentions this issue: internal/lsp: remove module diagnostics from code actions

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Mar 18, 2021

Thank you for these reports. We were able to debug this issue using the juju repository, and we'll have a patch release out to fix this soon. You can try it out now by downloading gopls at master: GO111MODULE=on go get golang.org/x/tools/gopls@master golang.org/x/tools@master. Please let us know if the issue is resolved at master.

gopherbot pushed a commit to golang/tools that referenced this issue Mar 19, 2021
…om code actions

With -mod=readonly, all go.mod diagnostics are covered by go get quick
fixes on import statements, so we don't need to run `go mod tidy` on
save for Go files. The real issue with this bug is the call to
WorkspacePackages, which type checks every package in the workspace.

Fixes golang/go#45092

Change-Id: Ibb82a3e58ec345ebdb67c0cbef5e029dce2d5a30
Reviewed-on: https://go-review.googlesource.com/c/tools/+/303149
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
(cherry picked from commit 2c4a886)
Reviewed-on: https://go-review.googlesource.com/c/tools/+/303150
@evanw
Copy link
Author

@evanw evanw commented Mar 21, 2021

I just updated and it appears to be fixed! Thanks so much for the fix.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Apr 1, 2021
0.6.9
This is a patch release to fix golang/go#45092.

0.6.8
This is a patch release to fix golang/go#45075.

0.6.7
New analyzers

The unusedwrite and nilness analyzers are now available, but they
are disabled by default. Note that enabling them permanently may
significantly increase memory usage. You can configure analyzers
through the analyses setting.  Improved hover with time.Duration

Hover for any constant of type time.Duration is shown both in
nanoseconds and as a human-readable string.

Fixes

A full list of all issues fixed can be found in the gopls/v0.6.7
milestone. To report a new problem, please file a new issue at
https://golang.org/issues/new.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants