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

x/tools/gopls: reduce CPU usage #36942

Open
stamblerre opened this issue Jan 31, 2020 · 5 comments
Open

x/tools/gopls: reduce CPU usage #36942

stamblerre opened this issue Jan 31, 2020 · 5 comments

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jan 31, 2020

gopls hogs the user's CPU when they are typing quickly, as it starts type-checking on every keystroke. We should debounce requests or otherwise reduce the frequency of type-checking as a user is editing their file.

@gopherbot gopherbot added this to the Unreleased milestone Jan 31, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls/v1.0.0 Jan 31, 2020
@myitcv
Copy link
Member

@myitcv myitcv commented Jan 31, 2020

History on this in #34569

@mvdan
Copy link
Member

@mvdan mvdan commented Feb 1, 2020

You could also be a bit smarter about what characters the user is typing. If the user is in the middle of typing an identifier or a string, it's unlikely that typechecking at every keystroke is going to be useful. However, if right after an identifier they type . or :, it's likely that an incremental typecheck would add useful information.

This doesn't have to be a binary decision, though. There could be a heuristic based on the time between keystrokes and the characters being typed, for example.

@myitcv
Copy link
Member

@myitcv myitcv commented Feb 1, 2020

Just to also note that I'm particularly seeing issues when govim starts in a medium-large project. gopls is so efficient at using all CPU power available, that the initial load makes my machine unusable. Whilst this cost will be amortised by #34111, the initial load for any project should probably max out at ~50% available CPU (just to pluck a figure from thin air)

@muirdm
Copy link

@muirdm muirdm commented Feb 2, 2020

I imagine we are going to end up with two type checking modes. We will have the heavily debounced (~500ms) full type checking for diagnostics, and we will have the tricksy minimal type checking used for synchronous operations like completion. The three main minimal type checking tricks I've seen discussed are:

  1. Don't type check func bodies except the one containing the cursor.
  2. Don't type check at all for edits that merely extend an identifer/string/comment (as suggested above by @mvdan).
  3. Use types.CheckExpr to incrementally type check the expression/statement containing the cursor.
  1. is probably the hardest and would provide limited benefit assuming 1) and 2) are implemented.
@dominikh
Copy link
Member

@dominikh dominikh commented Feb 3, 2020

I would even argue that not all diagnostics should run at the same rate (say, muir's 500ms). Some analyses (particularly in staticcheck) are much more expensive than others, and also point out larger bugs than what can be affected by typing 5 characters. A simple differentiator could be those analyses that work purely on the AST, and those that rely on an IR (go/ssa, staticcheck's IR). Building the IR form is an expensive operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.