Investigate Delayed Go-to-Definition Behavior in Editors

[DanielRosenwasser]

Today go-to-definition across files takes a minute in large projects when a file isn't currently opened in an editor.

// a.ts
import "./b.js" // <- jump to definition on this path

// b.ts
export function foo() {
}

It's not clear why this is the case when the language service is fully initialized and program loading has occured - the file path is already known (even when declaration maps are enabled). So it seems like the editor is taking a bit longer than it needs, or go-to-definition is being blocked by some other operation (which should potentially be considered lower-priority).

[DanielRosenwasser]

See also #34843 for a real project experiencing this.

[DanielRosenwasser]

I just spoke to @amcasey a bit - part of it seems to be that jumping into a file triggers a project load, but maybe that's fine.

The "I'm blocked from navigation" go-to-definition behavior that I'm more concerned about seems to come from Ctrl+Clicking or Cmd+Clicking which might trigger an immediate quick info request! That request will trigger a project load, and that project load will block the server on a "go-to-definition" request.

[DanielRosenwasser]

@mjbvz we should chat about this one this Thursday

[mjbvz]

@DanielRosenwasser Can you also test this in the latest VS Code insiders build to confirm this is still happening. I checked in a fix the hover issue @amcasey mentioned last week but am not sure if it would also fix this

[amcasey]

I think we decided that one or both of #35114 and #35115 were our best bet for resolving this.

[amcasey]

This is a tracking issue not aimed at any particular milestone.

[amcasey]

I'm not sure this is tracking anything specific.