x/tools/gopls: 100% CPU utilization with soft links

[silentred]

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

$ go version
go version go1.13.12 darwin/amd64

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jason/Library/Caches/go-build"
GOENV="/Users/jason/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jason/Desktop/projects/GOPATH"
GOPRIVATE=""
GOPROXY=""
GOROOT="/usr/local/opt/go@1.13/libexec"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go@1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jason/Desktop/projects/xxx/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 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/z5/6kmls3wj45v9f0c456grhdnc0000gn/T/go-build577824137=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

My go project dir is /my-project. In this dir, there is a webui sub dir, witch is initialized with npm. When I open VSCode to do changes on /my-project, gopls process keeps running at 700% CPU utility.

I used go pprof to generate a flame graph. There were lots of CPU running at filepath.EvalSymlinks and os.Stat. I guess it has something to do with node_modules. I moved webui dir out of /my-project, then CPU utility dropped to normal.

I hope gopls could support excluding files like vscode does. And I see a issue with the same request. #37697
#37697

The profiling file is attached.
pprof.samples.cpu.002.pb.gz

[stamblerre]

@silentred: In your case, would #37697 (comment) resolve the issue? Was the node_modules directory within a module or was it a folder directly beneath your workspace root?

[silentred]

@stamblerre The dir structure is like:

/my-project/
  pkg/
  webui/
    node_modules/
  go.mod

#37697 looks great. I think ignoring node_modules could fix this issue.

[stamblerre]

Thanks for sharing that info. Actually, in this case, #37697 wouldn't solve the issue, as the node_modules directory is within a module itself and not at the top-level. We would be able to avoid looking for modules in the node_modules directory, but we will still load any modules we find with a go list <module path>/... query. I don't think we will be able to ignore directories within modules until #37724 is resolved.

[silentred]

Thanks for the reply. I think ignoring the dir webui is also supposed to do the trick.

[stamblerre]

Oh good point. In that case, I will close this in favor of #37697.