mirror of
https://github.com/golang/go
synced 2024-10-01 05:28:33 -06:00
fda23558a1
Loading completion suggestions can be slow, especially in GOPATH mode where basically anything can change at any time. As a compromise, cache everything for 30 seconds. Specifically, after a completion operation finishes, if the cache is more than 30 seconds old, refresh it asynchronously. That keeps user-facing latency consistent, without chewing up CPU when the editor isn't in use. It does mean that if you walk away for an hour and come back, the first completion may be stale. In module mode this is relatively benign. The only things the longer caching affects are the main module and replace targets, and relevant packages in those will generally be loaded by gopls, so they'll have full, up-to-date type information regardless. In GOPATH mode this may be more troublesome, since it affects everything. In particular, go get -u of a package that isn't imported yet won't be reflected until the cache period expires. I think that's a rare enough case not to worry about. Change-Id: Iaadfd0ff647cda2b1dcdead9254b5492b397e86e Reviewed-on: https://go-review.googlesource.com/c/tools/+/205163 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org> |
||
|---|---|---|
| .. | ||
| browser | ||
| cache | ||
| cmd | ||
| debug | ||
| diff | ||
| fuzzy | ||
| protocol | ||
| snippet | ||
| source | ||
| telemetry | ||
| testdata | ||
| tests | ||
| code_action.go | ||
| command.go | ||
| completion_test.go | ||
| completion.go | ||
| definition.go | ||
| diagnostics.go | ||
| folding_range.go | ||
| format.go | ||
| general.go | ||
| highlight.go | ||
| hover.go | ||
| implementation.go | ||
| link.go | ||
| lsp_test.go | ||
| references.go | ||
| rename.go | ||
| reset_golden.sh | ||
| server.go | ||
| signature_help.go | ||
| symbols.go | ||
| text_synchronization.go | ||
| watched_files.go | ||
| workspace.go | ||