cmd/go: go list is incredibly slow on Windows 11 #75238
Description
Go version
go version go1.25.0 windows/amd64
Output of go env in your module/workspace:
set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=0
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\{user}\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\{user}\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\{user}\AppData\Local\Temp\go-build1520687272=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=C:\Users\{user}\source\testing\go.mod
set GOMODCACHE=C:\Users\{user}\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\{user}\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\{user}\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.25.0
set GOWORK=
set PKG_CONFIG=pkg-configWhat did you do?
When running go list on Windows, I'm getting some absolutely unbearable performance. This is notably being run from gopls which I have created an issue for here #75208, however I've managed to narrow down the culprit to the go commands being run within gopls.
The isolation of this issue I have boiled down to removing a single import from this very simple Go program with a completed empty go.mod.
package main
import (
"flag"
"fmt"
)
var testflag string
func main() {
flag.StringVar(&testflag, "", "", "")
fmt.Println("hi")
}
In testing I have tried disabling antivirus, clearing modcache, fully reinstalling go, and disabling all other VS Code extensions. I can say relatively confidently that this is not a VS Code related issue.
What did you see happen?
In my example, removing that single import takes roughly 5-10 seconds to be reconciled by gopls.
I'm seeing log output like
3.2420477s for GOROOT= GOPATH=C:\Users\{user}\go GO111MODULE=auto GOPROXY=off PWD=C:\Users\{user}\source\testing go list ...
1.6115993s for GOROOT= GOPATH=C:\Users\{user}\go GO111MODULE=auto GOPROXY=off PWD=C:\Users\{user}\source\testing go list ...
The full log output is linked in the original issue #75208.
I then chased this issue down further referencing #71981.
Using command go list -e -json=... -compiled=true -test=true -export=false -deps=true -find=false -pgo=off -debug-actiongraph="list.json" I get the follow output
0.627s 7.06% build sync/atomic
0.626s 14.10% build internal/cpu
0.318s 17.69% build internal/goexperiment
0.317s 21.26% build unicode
0.317s 24.83% build internal/goarch
0.317s 28.40% build unicode/utf8
0.316s 31.96% build unicode/utf16
0.316s 35.52% build structs
0.316s 39.09% build internal/goos
0.316s 42.65% build internal/itoa
0.316s 46.21% build math/bits
0.316s 49.77% build internal/trace/tracev2
0.316s 53.34% build internal/asan
0.316s 56.90% build internal/msan
0.315s 60.45% build internal/unsafeheader
0.315s 64.00% build internal/profilerecord
0.315s 67.55% build encoding
0.315s 71.10% build internal/coverage/rtcov
0.315s 74.65% build internal/syscall/windows/sysdll
0.315s 78.20% build internal/byteorder
And using go list -e -json=... -compiled=true -test=true -export=false -deps=true -find=false -pgo=off -debug-actiongraph="list.json" -p=1 I get better performance but only marginally.
0.311s 31.41% build encoding
0.308s 62.48% link test
0.308s 93.52% build internal/abi
0.013s 94.83% build runtime
0.006s 95.39% build math
0.003s 95.65% build internal/syscall/windows
0.003s 95.90% build os
0.002s 96.11% build internal/goexperiment
0.002s 96.26% build internal/syscall/execenv
0.002s 96.41% build unicode
0.002s 96.56% build iter
0.002s 96.72% build sync/atomic
0.002s 96.87% build internal/oserror
0.001s 96.98% build internal/runtime/sys
0.001s 97.09% build internal/syscall/windows/registry
0.001s 97.20% build reflect
0.001s 97.31% build test
0.001s 97.41% build internal/chacha8rand
0.001s 97.52% build internal/cpu
0.001s 97.62% build internal/race
Both of these, including the -p=1, are wildly slower than they should be. The performance I get on WSL2 locally and Pop OS! on a separate system is closer to 200ms.
What did you expect to see?
Realistically, a full reconciled code action should be taking 200-500ms in VS Code rather than 5-10s