gopls takes 300-600ms to print its "invalid command" message. Given the desire to support gopls as fast command-line tool in agent-based workflows, we should reduce it.
This command shows package initialization times. (Note that each of these is effectively further doubled because gopls starts itself as a child process for telemetry.)
$ go build -o x ./gopls && time GODEBUG=inittrace=1 ./x c 2>&1 | awk '{ print $5, $2 }' | sort -rn | head tools
11 golang.org/x/tools/gopls/internal/cache
4.3 golang.org/x/tools/go/analysis/passes/modernize
1.0 golang.org/x/tools/gopls/internal/debug
0.61 golang.org/x/tools/gopls/internal/golang
0.28 honnef.co/go/tools/simple/s1018
0.23 encoding/gob
0.22 golang.org/x/tools/internal/stdlib
0.17 github.com/google/go-cmp/cmp
0.14 github.com/BurntSushi/toml/internal
0.11 honnef.co/go/tools/simple/s1012
modernize is high on the list because it keeps calling ExtractDoc to parse the same very large doc comment for each analyzer. Perhaps we should rethink ExtractDoc entirely, especially given the conclusion of #63659, which is that complete docs belong on the web and the CLI should just link to them.
gopls takes 300-600ms to print its "invalid command" message. Given the desire to support gopls as fast command-line tool in agent-based workflows, we should reduce it.
This command shows package initialization times. (Note that each of these is effectively further doubled because gopls starts itself as a child process for telemetry.)
modernizeis high on the list because it keeps calling ExtractDoc to parse the same very large doc comment for each analyzer. Perhaps we should rethink ExtractDoc entirely, especially given the conclusion of #63659, which is that complete docs belong on the web and the CLI should just link to them.