Visual F# Colorization, Intellisense super slow

[realvictorprm]

The Visual F# extension is creppy slow on my laptop and for @NatElkins since Friday last week.
Meant is that both colorization and intellisense take ages for showing and updating content so that nice coding isn't possible.

Repro steps

1. Open a solution which contains F# projects
2. Open a F# file
3. Wait...

Expected behavior

Fast colorization and Intellisense.

Actual behavior

Colorization takes more than one minute to appear, even longer.
Intellisense needs more than half an minute to appear after the Colorization appeared.

Known workarounds

Downgrade

Related information

Provide any related information

• Operating system: Win10
• Branch: Latest nightlies so master

[dsyme]

@realvictorprm

• A repro would be great please.
• I'm wondering if this is related to the fix in use graph of option objects - fix 2793 #3002. This may have enabled "cross- project" references in more situations,
• Does this happen on every time you change a file or only on the first colorization?

[NatElkins]

I notice that in VisualFSharp.sln if I go to il.fs I get colorization and Intellisense quickly and without issue. When I go to something like MSBuildUtilities.fs, it takes much, much longer.

[NatElkins]

Another piece of anecdotal evidence: the "lower down" in the stack my projects are (i.e. less transitive dependencies, things like domain types) the faster I get colorization and Intellisense.

[dsyme]

Another piece of anecdotal evidence: the "lower down" in the stack my projects are (i.e. less transitive dependencies, things like domain types) the faster I get colorization and Intellisense.

Asking agani: is that first-time colorization (open a file), or iterative colorization (after changing a file)? thanks

[realvictorprm]

@dsyme I'm very sorry that I cannot provide that much information on this.

first-time colorization

[dsyme]

@realvictorprm Thanks!

[dsyme]

@realvictorprm @NatElkins It is possible we will turn off cross-project checking (without compilation - i.e. checking against in-memory files rather than compiled DLLs on disk) by default and make it opt-in.

[realvictorprm]

I'm not yet into the details @dsyme. I would debug the stuff but debugging isn't even possible on my main computer. Too slow.

[0x53A]

I sometimes have the same issue - colorization takes minutes or it is seemingly never colorized (that is, first time colorization after opening the file) - is there something I can do to help?

What I could do is attach a debugger while it is uncolored and check what it is doing at that moment - any pointers where to look for that?

I do not have a reliable reproduction yet ...

[dsyme]

@0x53A You may find your problems are less severe on master after #3061

@realvictorprm @0x53A Re this:

I sometimes have the same issue - colorization takes minutes or it is seemingly never colorized (that is, first time colorization after opening the file) - is there something I can do to help?

Try this:

1. get and build master
2. Start administrator VisualFSharp.sln
3. Choose startup project VisualFSharpOpenSource
4. Choose "Release" configuration
5. Hit F5 to build and launch VS experimental (lets call that your "target VS")
6. In your target VS load your project and get ready to do your stuff
7. In your debugger clear the Output window
8. In your target VS do your stuff
9. In your debugger: grab the Output window and paste it into a gist
10. exit

We only want the accurate part of the log corresponding to the time period over which colorization was not active.

BTW is it all kinds of colorization or just semantic colorization?