Fsharp: Type checking responsiveness in IDE

[isaksky]

Type checking with Intellisense takes too long to be useful in some cases, possibly related to having a large number of types.

Repro steps

Have a large number of types, make a change to the code, and wait for visual studio to type check the program:

Can repro by building this project and opening this file:

https://github.com/isaksky/FsSqlDom/blob/master/examples/GraphTableRelationships.fsx

Expected behavior

Intellisense works in at most 1 second (red line appearing above). I'm not sure exactly what upper bound would be reasonable, but if it takes more than a second or two, it is hard to make use of it.

Actual behavior

Intellisense takes about 7 seconds.

Related information

I did a profile of the same problem in Ionide (PerfView could not seem to handle profiling VS 2017), and got these results, showing some hot spots in the code:

Using Windows 10, Visual Studio 2017, latest F# Nightly tools as of 5/7/2017

Example library from Microsoft with large number of types:

https://msdn.microsoft.com/en-us/library/microsoft.sqlserver.transactsql.scriptdom.aspx

https://www.nuget.org/packages/Microsoft.SqlServer.TransactSql.ScriptDom/

The library where the problem appears generates F# DUs from this type hierarchy, and methods to convert back and forth.

[vasily-kirichenko]

Minimal repro (the rest of the script is commented out)

@dsyme I think the problem is not with slow compiler (we can do very little with it), but with rechecking that FsSqlDom.dll assembly every time the script is type checked. Clearly it's a bug.

[vasily-kirichenko]

I've checked if we pass same FSharpProjectOptions to checker - we do. Options created here https://github.com/Microsoft/visualfsharp/blob/master/vsintegration/src/FSharp.Editor/LanguageService/LanguageService.fs#L141 is same as cached (in sense of FSharpProjectOptions.AreSameForChecking). I've no further ideas why checker rechecks assemblies.

[vasily-kirichenko]

getOrCreateBuilder returns cached IncrementalBuilder, so something wrong with imported assemblies cache?

[dsyme]

Yeah must be something wrong with the "timestamp" logic. I was looking at some related issues today. Will take a look tomorrow

[vasily-kirichenko]

Expected behavior: Intellisense works in at most 1 second (red line appearing above). I'm not sure exactly what upper bound would be reasonable, but if it takes more than a second or two, it is hard to make use of it.

Unfortunately, we cannot change the delay Roslyn takes before asks us for fresh diagnostics analysis after a document is changed. If I remember correctly it's about 1.5 seconds. @CyrusNajmabadi explained that they did a research and conclude that such delays are the most comfortable for developers. Read this https://github.com/dotnet/roslyn/issues/18376

[dsyme]

Unfortunately, we cannot change the delay Roslyn takes before asks us for fresh diagnostics analysis after a document is changed. If I remember correctly it's about 1.5 seconds. @CyrusNajmabadi explained that they did a research and conclude that such delays are the most comfortable for developers. Read this dotnet/roslyn#18376

@vasily-kirichenko @CyrusNajmabadi - I've noticed this problem too and I do feel like the delay is too long for F# programmers, particularly when writing data scripts. I'm not sure why - but I think the highly type-inferred nature of F# may mean that people rely on the presence of red-squigglies to give very quick error feedback.

I'll comment more on the roslyn thread mentioned above, but I'd like us to try to make this configurable for F#.

[CyrusNajmabadi]

We could definitely expose this through an API so you could configure it for F#.

[vasily-kirichenko]

@CyrusNajmabadi please, expose it.

[dsyme]

@CyrusNajmabadi Yes, pretty please with sugar on top :)

[cartermp]

Issue on Roslyn here: https://github.com/dotnet/roslyn/issues/19347

[dsyme]

We've investigated the delays and made considerable improvements https://github.com/Microsoft/visualfsharp/pull/3238. This includes a fix for a potentially unbounded delay in large files, as described in the PR, as well as other improvements

[dsyme]

@isaksky I looked at your repro

https://github.com/isaksky/FsSqlDom/blob/master/examples/GraphTableRelationships.fsx

In normal editing in that file errors now take 3-4 seconds to refresh

[isaksky]

@dsyme This is great news!

[dsyme]

@isaksky Please try master or nightlies as they become available. The more you can validate (and find new issues with repros) the better

BTW all the very best for XLedger - exciting!

[toburger]

I can confirm that build 15.4.1.17062301 is now much faster and responsive.