Add configuration option for diagnostic delays in editor

[cartermp]

This is from this comment: #18376 (comment)

F# is hurt a bit by artificial delays in squiggles in the editor. Because we have type inference, people rely on instant feedback on if something will work via squiggles (or lack thereof). Because type inference already takes quite a bit of time, any additional delay gives the appearance the editor is unresponsive in certain scenarios for F#.

A configuration flag to opt out of these delays would be great. We would configure this in our editor layer.

[isaacabraham]

Perhaps a slightly nicer option would be to be able to set the minimum delay. @CyrusNajmabadi makes a valid point that I've noticed in the past - if you get instant feedback whilst typing and get squigglies in the middle of typing, it can be annoying. If it was possible to set the delay at no less than e.g. 150ms this would avoid that concern, and also (hopefully) help ensure that the IDE responsiveness was more or less consistent across different files.

[Pilchie]

Tagging @heejaechang and @jinujoseph about this request.

[heejaechang]

it is a bit hard since that delay is shared by every one. not just F#.

[CyrusNajmabadi]

We can certainly make it configurable on a per-feature basis.

[isaacabraham]

@heejaechang optional argument maybe?

[heejaechang]

presentation can be slowed. but actual work (computing diagnostics) can't be controlled per language or feature right now. the delay for actual work is there to reduce work we do on each key stroke. otherwise, we will produce too much garbage that will affect typing responsiveness. (allocation rate goes up, GC runs more often and etc)

current delay is set to current number after years of tweaking from our typing responsiveness perf result.

but that being said, we could (even though it is some work) make delay to be per language somehow since each language might have different cost on computing diagnostics. for C# and VB, that is most expansive thing to compute.

[dsyme]

@heejaechang @CyrusNajmabadi The current delay for F# "document analysis" in order to update red squigglies is really, really long. We have quite a problem here

The frustrating thing is that other analysis such as semantic happens very quickly - and for F# the semantic colorization involves doing all the work necessary for document analysis (red squigglies). So F# is all ready to report the errors, but Roslyn takes a long time before the errors are shown

I would really like to make progress on this. The default settings that Roslyn are using appear to be wrong for F# - people using F# expect much faster red-squiggly appearance than we're currently getting. Perhaps it is our fault (are the previous stages taking too long?), but I feel it is also to do with Roislyn (e.g. is Roslyn analyzing the wrong files, rather than concentrating on the active buffers???)

[heejaechang]

@dsyme can you experiment with numbers to see what affects your scenario. if you build Roslyn.sln, and run devenv /rootsuffix RoslynDev you will see this in options.

try reduce Active File worker backoff timespan in ms to something like 100ms or lower. you probably want some delay there still to reduce allocations.

we arrived to 400ms to reduce typing response time due to garbage produced by diagnostics.

[Pilchie]

Updated comment above to say RoslynDev instead of Roslyn for the rootsuffix argument.