lsp: investigate prioritizing the generation of diagnostics to the last modified or opened file

[dsherret]

Instead of (1) collecting diagnostics for all open documents and (2) publishing diagnostics. We might want to consider (1) collecting diagnostics for the last modified/opened file, (2) publish these diagnostics, (3) collect diagnostics for the other files, (4) publish these other diagnostics.

This would take longer overall, but my guess would be that it would give the impression that the lsp is faster. To implement, the diagnostic update sent from the LanguageServer to DiagnosticsServer would include a collection of specifiers to prioritize.

One downside to this, is that it would make the LSP tests more complicated so this would be a largish task to implement. If/when implementing we should create a way to make testing the LSP easier and not as verbose.

[kitsonk]

I would expect that it would take significantly longer and not produce initial results faster. Whenever you calculate diagnostics, tsc will check the entire dependency graph of the project is fresh, make any updates to the project, etc before calculating diagnostics.

Way back when we saw a significant performance improvement by batching all requested specifiers into a single request, which is why we went down that path.

It is worth investigating, but whatever upside to splitting them out would is unlikely to be noticeable to the user, and only likely "backup" the queue of work to calculate would be my hypothesis.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[lucacasonato]

With TS 5.6 we can extend this to generate diagnostics for a section of a file that is currently visible: https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#region-prioritized-diagnostics-in-editors