commit f0be937dca51bc8962f3aeb3914da0aaed69a39c
author Muir Manders <muir@mnd.rs> Fri Aug 16 09:45:09 2019 -0700
committer Rebecca Stambler <rstambler@golang.org> Tue Aug 20 18:51:39 2019 +0000
tree 0bc32c2ce250e8dc397ec82a3b97d956748c8b31
parent 85edb9ef328312eeb9315a7707cbb661702d17f9

internal/lsp: speed up deep completion search

Optimize a few things to speed up deep completions:

- item() is slow, so don't call it unless the candidate's name matches
  the input.
- We only end up returning the top 3 deep candidates, so skip deep
  candidates early if they are not in the top 3 scores we have seen so
  far. This greatly reduces calls to item(), but also avoids a
  humongous sort in lsp/completion.go.
- Get rid of error return value from found(). Nothing checked for this
  error, and we spent a lot of time allocating the only possible error
  "this candidate is not accessible", which is not unexpected to begin
  with.
- Cache the call to types.NewMethodSet in methodsAndFields(). This is
  relatively expensive and can be called many times for the same type
  when searching for deep completions.
- Avoid calling deepState.chainString() twice by calling it once and
  storing the result on the candidate.

These optimizations sped up my slow completion from 1.5s to
0.5s. There were around 200k deep candidates examined for this one
completion. The remaining time is dominated by the fuzzy
matcher. Obviously 500ms is still unacceptable under any
circumstances, so there will be subsequent improvements to limit the
deep completion search scope to make sure we always return completions
in a reasonable amount of time.

I also made it so there is always a "matcher" set on the
completer. This makes the matching logic a bit simpler.

Change-Id: Id48ef7031ee1d4ea04515c828277384562b988a8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/190522
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>