1
0
mirror of https://github.com/golang/go synced 2024-11-18 16:24:42 -07:00
go/internal/lsp/source/deep_completion.go

217 lines
6.2 KiB
Go
Raw Normal View History

// Copyright 2019 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package source
import (
"context"
"go/types"
"strings"
"time"
)
// MaxDeepCompletions limits deep completion results because in most cases
// there are too many to be useful.
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>
2019-08-16 10:45:09 -06:00
const MaxDeepCompletions = 3
// deepCompletionState stores our state as we search for deep completions.
// "deep completion" refers to searching into objects' fields and methods to
// find more completion candidates.
type deepCompletionState struct {
// maxDepth limits the deep completion search depth. 0 means
// disabled and -1 means unlimited.
maxDepth int
// chain holds the traversal path as we do a depth-first search through
// objects' members looking for exact type matches.
chain []types.Object
// chainNames holds the names of the chain objects. This allows us to
// save allocations as we build many deep completion items.
chainNames []string
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>
2019-08-16 10:45:09 -06:00
// highScores tracks the highest deep candidate scores we have found
// so far. This is used to avoid work for low scoring deep candidates.
highScores [MaxDeepCompletions]float64
// candidateCount is the count of unique deep candidates encountered
// so far.
candidateCount int
}
// push pushes obj onto our search stack. If invoke is true then
// invocation parens "()" will be appended to the object name.
func (s *deepCompletionState) push(obj types.Object, invoke bool) {
s.chain = append(s.chain, obj)
name := obj.Name()
if invoke {
name += "()"
}
s.chainNames = append(s.chainNames, name)
}
// pop pops the last object off our search stack.
func (s *deepCompletionState) pop() {
s.chain = s.chain[:len(s.chain)-1]
s.chainNames = s.chainNames[:len(s.chainNames)-1]
}
// chainString joins the chain of objects' names together on ".".
func (s *deepCompletionState) chainString(finalName string) string {
s.chainNames = append(s.chainNames, finalName)
chainStr := strings.Join(s.chainNames, ".")
s.chainNames = s.chainNames[:len(s.chainNames)-1]
return chainStr
}
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>
2019-08-16 10:45:09 -06:00
// isHighScore returns whether score is among the top MaxDeepCompletions
// deep candidate scores encountered so far. If so, it adds score to
// highScores, possibly displacing an existing high score.
func (s *deepCompletionState) isHighScore(score float64) bool {
// Invariant: s.highScores is sorted with highest score first. Unclaimed
// positions are trailing zeros.
// If we beat an existing score then take its spot.
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>
2019-08-16 10:45:09 -06:00
for i, deepScore := range s.highScores {
if score <= deepScore {
continue
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>
2019-08-16 10:45:09 -06:00
}
if deepScore != 0 && i != len(s.highScores)-1 {
// If this wasn't an empty slot then we need to scooch everyone
// down one spot.
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>
2019-08-16 10:45:09 -06:00
copy(s.highScores[i+1:], s.highScores[i:])
}
s.highScores[i] = score
return true
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>
2019-08-16 10:45:09 -06:00
}
return false
}
// scorePenalty computes a deep candidate score penalty. A candidate
// is penalized based on depth to favor shallower candidates. We also
// give a slight bonus to unexported objects and a slight additional
// penalty to function objects.
func (s *deepCompletionState) scorePenalty() float64 {
var deepPenalty float64
for _, dc := range s.chain {
deepPenalty += 1
if !dc.Exported() {
deepPenalty -= 0.1
}
if _, isSig := dc.Type().Underlying().(*types.Signature); isSig {
deepPenalty += 0.1
}
}
// Normalize penalty to a max depth of 10.
return deepPenalty / 10
}
func (c *completer) inDeepCompletion() bool {
return len(c.deepState.chain) > 0
}
// shouldPrune returns whether we should prune the current deep
// candidate search to reduce the overall search scope. The
// maximum search depth is reduced gradually as we use up our
// completionBudget.
func (c *completer) shouldPrune() bool {
if !c.inDeepCompletion() {
return false
}
// Check our remaining budget every 100 candidates.
if c.opts.budget > 0 && c.deepState.candidateCount%100 == 0 {
spent := float64(time.Since(c.startTime)) / float64(c.opts.budget)
switch {
case spent >= 0.90:
// We are close to exhausting our budget. Disable deep completions.
c.deepState.maxDepth = 0
case spent >= 0.75:
// We are running out of budget, reduce max depth again.
c.deepState.maxDepth = 2
case spent >= 0.5:
// We have used half our budget, reduce max depth again.
c.deepState.maxDepth = 3
case spent >= 0.25:
// We have used a good chunk of our budget, so start limiting our search.
// By default the search depth is unlimited, so this limit, while still
// generous, is normally a huge reduction in search scope that will result
// in our search completing very soon.
c.deepState.maxDepth = 4
}
}
c.deepState.candidateCount++
if c.deepState.maxDepth >= 0 {
return len(c.deepState.chain) >= c.deepState.maxDepth
}
return false
}
// deepSearch searches through cand's subordinate objects for more
// completion items.
func (c *completer) deepSearch(ctx context.Context, cand candidate) {
if c.deepState.maxDepth == 0 {
return
}
obj := cand.obj
// If we are definitely completing a struct field name, deep completions
// don't make sense.
if c.wantStructFieldCompletions() && c.enclosingCompositeLiteral.inKey {
return
}
// Don't search into type names.
if isTypeName(obj) {
return
}
if obj.Type() == nil {
return
}
// Don't search embedded fields because they were already included in their
// parent's fields.
if v, ok := obj.(*types.Var); ok && v.Embedded() {
return
}
if sig, ok := obj.Type().Underlying().(*types.Signature); ok {
// If obj is a function that takes no arguments and returns one
// value, keep searching across the function call.
if sig.Params().Len() == 0 && sig.Results().Len() == 1 {
// Pass invoke=true since the function needs to be invoked in
// the deep chain.
c.deepState.push(obj, true)
// The result of a function call is not addressable.
c.methodsAndFields(ctx, sig.Results().At(0).Type(), false, cand.imp)
c.deepState.pop()
}
}
// Push this object onto our search stack.
c.deepState.push(obj, false)
switch obj := obj.(type) {
case *types.PkgName:
c.packageMembers(ctx, obj.Imported(), stdScore, cand.imp)
default:
c.methodsAndFields(ctx, obj.Type(), cand.addressable, cand.imp)
}
// Pop the object off our search stack.
c.deepState.pop()
}