Typechecking is sometimes very slow

[drvink]

FsControl is a library which makes heavy use of static members on classes and SRTP to enable typeclass-like functionality in F#. Unfortunately, it seems to tickle some pathological case in the F# typechecker, as it often takes minutes to complete. In Emacs with the fsautocomplete process, it usually outright times out, but in Visual Studio the wait is unbounded and you usually end up having to kill VS.

Try editing this file after compiling the library--simply making changes within it should cause VS or the autocompletion process to churn.

[drvink]

Looks like fsautocomplete sometimes crashes too. This is the backtrace VS gives when I debug it:

System.Exception was unhandled
Message: An unhandled exception of type 'System.Exception' occurred in FSharp.Core.dll
Additional information: Exception when getting check options for 'c:\Users\msjp_000\Desktop\FsControl\NewHaskell.fsx'
.Details: System.TimeoutException: The operation has timed out.
   at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at FSharp.CompilerBinding.LanguageService.GetScriptCheckerOptions(String fileName, String projFilename, String source)

And this is a backtrace that appears in Emacs:

Unhandled Exception: System.Exception: Exception when getting check options for 'c:\\Users\\msjp_000\\Desktop\\FsControl\\NewHaskell.fsx'
.Details: System.TimeoutException: The operation has timed out.
   at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at FSharp.CompilerBinding.LanguageService.GetScriptCheckerOptions(String fileName, String projFilename, String source)
   at <StartupCode$FSharp-Core>.$Control.StartImmediate@1412-1.Invoke(Exception exn)
   at Microsoft.FSharp.Control.CancellationTokenOps.StartWithContinuations@1198-1.Invoke(Exception x)
   at Microsoft.FSharp.Control.Trampoline.ExecuteAction(FSharpFunc`2 firstAction)
   at Microsoft.FSharp.Control.AsyncBuilderImpl.startAsync[a](CancellationToken cancellationToken, FSharpFunc`2 cont, FSharpFunc`2 econt, FSharpFunc`2 ccont, FSharpAsync`1 p)
   at Microsoft.FSharp.Control.CancellationTokenOps.StartWithContinuations[T](CancellationToken token, FSharpAsync`1 a, FSharpFunc`2 cont, FSharpFunc`2 econt, FSharpFunc`2 ccont)
   at Microsoft.FSharp.Control.FSharpAsync.StartWithContinuations[T](FSharpAsync`1 computation, FSharpFunc`2 continuation, FSharpFunc`2 exceptionContinuation, FSharpFunc`2 cancellationContinuation, FSharpOption`1 cancellationToken)
   at Microsoft.FSharp.Control.FSharpAsync.StartImmediate(FSharpAsync`1 computation, FSharpOption`1 cancellationToken)
   at FSharp.InteractiveAutocomplete.Main.main(State state)
   at FSharp.InteractiveAutocomplete.Main.entry(String[] args)

[radekm]

Seems related to #343.

[drvink]

Ah, yes, this is almost certainly the same issue.

Regarding @dsyme's comment here, I've seen this same problem with much, much simpler libraries and example cases than FsControl (I was working on a library with a similar goal myself until I found out someone had already done it better than me :)). The performance of the type checker can get pretty abysmal even if you fix all top-level declarations (and any others that fail to be unambiguously inferred) with type signatures, so I'm afraid there really isn't a very good workaround available...

[dsyme]

Closing this as it looks like a dup of 343. @drvink - if you can give a simpler repro than the extensive overloading inn FsControl that would be great, thanks.