x/tools/gopls: very slow startup without go.mod or go.work

[pjweinb]

The command 'gopls semtok /tmp/a.go' takes 84 seconds when run in my home directory on my Mac. (a.go is short: 'package main; func main(){}') Most users would not see this problem because they would invoke gopls from an editor.

All the time is spent in findModules. It's called twice, once for findWorkspaceRoot (27.7 elapsed seconds) and once for newWorkspace (53.2 elapsed seconds). With a go.work file added, it instead finishes instantaneously. The file tree rooted at home directories tends to be large on Macs, because it include s./Library, which, for me, is 500,000 files.

[findleyr]

Thanks for investigating. We can eliminate the search for modules in newWorkspace -- this is really not the correct place to be finding modules now that experimentalWorkspaceModule is deprecated.

However, it would be harder to remove the feature that gopls narrows the workspace to a nested module, if it finds one. This is a common use-case when opening a multi-language repo in vs code.

The scan is limited to 1e6 files, based on benchmarking (on Linux, I'm afraid). It sounds like that limit is too high, and we should instead limit to ~1e5 or fewer.

[gopherbot]

Change https://go.dev/cl/448695 mentions this issue: internal/lsp/cache: clean up workspace information tracking

[findleyr]

@pjweinb what do you think we should do about finding template files? Perhaps just search recursively from the first time a template file is opened?