Fsharp: Slow initial IDE performance, when Loading FSharp.Core project.

[OnurGumus]

When I open a project like FSharp.Core in VisualFSharp with VS 2017 RC3, the CPU peaks quite for a while. Here are the perfview traces:

Perhaps for these bottlenecks, using BCL Imperative collections should be considered instead of the FSharp immutable ones.

[vasily-kirichenko]

It's typechecking. It's OK.

[OnurGumus]

@vasily-kirichenko but can't this type checking be done more efficiently?

[vasily-kirichenko]

No.

[KevinRansom]

@OnurGumus ...
perhaps ... however ... no one has come up with a more performant approach so far. And it has been slooooow for a very long time.

[cartermp]

@OnurGumus While I'm sure typechecking could be made more efficient if someone were to look at it in-depth for a very long time, it's a very significant effort.

[OnurGumus]

Maybe I am naïve but , using imperative collections and imperative loops will help immediately, no? I am sure you guys already thought about it, but I am just curious, why that' wouldn't be sufficient ?

[vasily-kirichenko]

@OnurGumus In short, to obtain info to make all the features work (syntax highlighting, find usages, rename, etc, etc.) we need to compile the whole project. Measure how much it takes to compile your project. That should match that initial pause you are talking about.

[cartermp]

IIRC @vasily-kirichenko did profile using Dictionary<'T, 'U> in some language service code and didn't see any performance gains. That doesn't mean using different collection types in typechecking wouldn't be an improvement, but this requires detailed profiling to identify why behavior is the way it is, and I wouldn't be surprised if we saw similar results. Surely there are some heavy data structures which could be trimmed as well, but as with collection types this would have to be profiled effectively. This is before any of the significant cost involved of swapping out an immutable structure with a mutable one, which could violate any assumptions we have about immutability in the codebase. In short, not a simple task.

[vasily-kirichenko]

The things are not that simple. We cannot replace Map with Dictionary in name resolution environment, for example because it means cloning (copying) _a lot_ of dictionaries (currently all maps share common nodes, (very) naturally).

[dsyme]

@vasily-kirichenko It's certainly true that we've always done the background type checking of projects

However I don't understand why IsRelativeNameResolvable would be on the background checking path - it's not part of the normal process of type checking, and seems more related to some new IDE feature such as finding suggestions for opening namespaces? So it could be that this perf view trace indicates an unoptimized path in the language service implementation of a new IDE feature

I just want to check that we're not labeling CPU usage as "doing type checking" when we're really doing something new?

thanks
don

[vasily-kirichenko]

@dsyme it must be (now disabled) Simplify name analyzer.

[dsyme]

@vasily-kirichenko Got it, thanks

[vasily-kirichenko]

@dsyme or it may be Roslyn's all files background analyzing, which we turned off in master. It took ~20 minutes one core 100% loaded after a singe change on VFT solution.

[vasily-kirichenko]

...and RTW is released with this enabled...

[dsyme]

@dsyme or it may be Roslyn's all files background analyzing, which we turned off in master. It took ~20 minutes one core 100% loaded after a singe change on VFT solution.

I think the presence of IsRelativeNameResolvable in the trace indicates it's an IDE feature

[vasily-kirichenko]

Ah, yes, sorry. Then it's Simplify name analyzer for sure.

[OnurGumus]

Just in case I am adding the traces and perfview itself as a zip file.
https://1drv.ms/u/s!AsiXNzy93_kOnY1KiLsoVT5BukxaMA

[dsyme]

Closing since the "Simplify name analyzer" is disabled by default, and we believe this is what's responsible