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

Jump to bottom

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

Closed
pjweinb opened this issue Oct 31, 2022 · 4 comments
Closed

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

pjweinb opened this issue Oct 31, 2022 · 4 comments
Assignees
@findleyr
Labels
gopls/performance Issues related to gopls performance (CPU, memory, etc). gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
gopls/v0.12.0

Comments

@pjweinb
Copy link

pjweinb commented Oct 31, 2022

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.
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Oct 31, 2022
@gopherbot gopherbot added this to the Unreleased milestone Oct 31, 2022
@findleyr
Copy link
Contributor

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
Copy link

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

@findleyr findleyr modified the milestones: gopls/v0.11.0, gopls/v0.12.0 Dec 9, 2022
@renthraysk renthraysk mentioned this issue Jan 9, 2023
Closed
@findleyr findleyr mentioned this issue Jan 24, 2023
Closed
13 tasks
@findleyr
Copy link
Contributor

@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?

@findleyr findleyr added the gopls/performance Issues related to gopls performance (CPU, memory, etc). label May 16, 2023
@gopherbot
Copy link

Change https://go.dev/cl/496880 mentions this issue: gopls/internal/lsp/cache: limit module scan to 100K files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@findleyr findleyr

Labels
gopls/performance Issues related to gopls performance (CPU, memory, etc). gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
gopls/v0.12.0
Development

No branches or pull requests
3 participants
@pjweinb @gopherbot @findleyr