Completion list takes far too long even after an initial list is generated

[jaredpar]

edits by @cartermp

Current issue:

Thanks to @buybackoff for the repro:

1. Download Spreads.
2. Build the solution (build.cmd)
3. Open the solution and theSortedMap.fs file.
4. Add a new line after line 125, and type this.

Expected: completion list appears reasonably fast, at least certainly after the first try.

Actual: completion appears many seconds after the . every time.

Old issue:

Recently started playing around with VsVim on 15.6 preview 2 and noticed that Intellisense is extremely slow. At first I thought it was broken but eventually found it's just taking ~6-8 seconds to display. This reproduces consistently.

1. Clone https://github.com/jaredpar/VsVim
2. Switch to branch repro/fsharp-intellisense-perf
3. Open VsVim.sln
4. Open Modes_Visual_VisualMode.fs
5. Wait for semantic colorizing to take place (ensure initial binding pass is done).
6. Navigate to line 223. Will have text _selectionTracker.UpdateSelection()
7. Open a line above and type _selectionTracker.

I would expect Intellisense to popup rather quickly here. Instead it takes ~8 seconds to popup. You can delete the . and retype and see the effect over and over again.

Of possible interest here is this F# project is on the new SDK.

[dsyme]

That certainly sounds like either

1. the FCS caching is not taking effect for new-style projects, or
2. there are a lot of options being recomputed for new-style projects

[jaredpar]

Checked and I'm seeing the same behavior on 15.5.4 as well. Changed title to reflect that it's not specific to the preview.

[jaredpar]

FYI: updated the repro instructions. The perf is bad enough that I need to move back to the classic SDK for now. Saved the current state though in repro/fsharp-intellisense-perf branch

[cartermp]

Yeah, stuff seems to be needlessly recomputed here and it's not just the delay in the editor:

Note that successive . gives a spike in CPU usage even though nowhere near enough memory is being used to force things out of caches.

Also noticed a bug where SelectionTracker is being favored over _selectionTracker in completion, but that's unrelated to this.

[jaredpar]

Once I moved back to the old SDK the issue went away. Only been a few minutes but everything seems to be behaving as I would expect.

[forki]

I can repro. old sdk fast - new sdk branch slow

[cartermp]

Labeling as Now since this is clearly a blocker for anyone who has a similar situation as @jaredpar