VS2017 RC2 intellisense blocks the GUI

[gusty]

I've tested editing projects like FSharpPlus which makes heavy use of overload resolution, with the new Visual Studio 2017 and found that now it seems that the UI is blocked until intellisense finish inferring the types.

Since overload resolution time was improved this is not a big issue, I prefer it to the old Visual Studio but each time the code is edited the whole UI is blocked for a few seconds in my computer which is not very fast.

Repro steps

1. Open FSharpPlus

2. Go to a file, like operators.fs and rename a function.

Expected behavior

The GUI continues working while type inference works on the background.

Actual behavior

The GUI is blocked. Scroll bars, cursor, everything freezes for a very few seconds.

Known workarounds

I don't know any interesting workaround at the moment.

Related information

• Operating system: Windows 10 Pro N
• Branch: RC2
• .NET Runtime, CoreCLR or Mono Version: 4.6.01586
• Editing Tools (e.g. Visual Studio Version): 2017 RC2
• Links to F# RFCs or entries on http://fslang.uservoice.com: N/A
• Links to performance testing scripts: N/A
• Indications of severity: Medium to High

[vasily-kirichenko]

See #1825, in short, it's fixed on roslyn side, we will check if the fix works as new roslyn nuget published.

[gusty]

Thanks, but are you sure it's the same issue?
That issue is with CTRL+SPACE, I've seen problems with that long before VS 2017, I remember once I had to restart my PC and lost the work.
Otherwise let's wait until the nuget is published.

[vasily-kirichenko]

Ah, sorry, I read the issue not carefully enough. If you have UI freezes during code editing (no intellisense involved), than check devenv.exe process private set. If it exceeds 2GB, nothing can help - blocking GC kills UI. Restart VS is the only way to fix this. However, on the compiler project you reach 2GB very quickly. The cause are FSC caches, I've no idea how to reduce their memory appetite.

[gusty]

Also that issue, I think, is a different issue. I see the memory of devenv.exe around 225 MB.
If you don't have a superfast computer you can try open a code file on that project, you will see the freeze as soon as you open it, it freezes for a short time until it colours the code, them each time you edit something freezes again.

[vasily-kirichenko]

We use Roslyn API for everything, including colorizing, error/warning reporting, etc. That API is fully asynchronous, I mean all the methods we implemented return Task<...>. So, if there are UI freezes they are rooted to Roslyn itself.

Could you please profile VS with dotTrace in its "Timeline" mode? It will show UI freezes explicitly, like this:

[vasily-kirichenko]

@gmpl I cannot build FSharpPlus:

Looks like you don't use FSharp.Core NuGet package:

I don't have VS 2013 / F# 3.1-4.0 installed.

[vasily-kirichenko]

I cannot reproduce it:

[gusty]

Yes, the build was broken but now it's fine.
It seems it works fine for you.
I will see if there is an update for the VS.

[vasily-kirichenko]

This is the version info:

I have a fairly fast machine (i7-4790K at 4GHz). However, I don't experience any freezes or delays, even sub second ones.

[gusty]

Hmmm, it's the same VS version I have.
It definitely works fine for you from what I can see in your video.
I do have VS2015 installed on the same OS.

[vasily-kirichenko]

I have no more ideas but a suggestion to profile VS with dotTrace.

[gusty]

Yes, that's exactly what I'm looking for.
It might give us more precise information.

[gusty]

After installing dotTrace I found the Timeline option but don't get to that screen.
Could you explain me the steps to get to the window with UI freezes?
Thanks

[cartermp]

I can't repro this either. Type colorization is a bit slow on some of the larger files (as I would expect), but I don't notice any UI blockage. As @vasily-kirichenko mentioned, every editor API that we implement is asynchronous, with the exception of completions via ctrl-space (and that's actually been changed by the Roslyn team to allow for asynchrony).

Hopefully we can figure out why this is happening on your machine.

[vasily-kirichenko]

@gmpl

[gusty]

After many attempts with many errors (my disk was full) I managed to capture the snapshot.
Do you want me to upload it somewhere?
Or I can send it to you by email if you want.

[vasily-kirichenko]

Share it, please, maybe somebody else likes to loot at it as well.

[gusty]

Here's the file with the snapshot. Hope it helps.

[vasily-kirichenko]

Look at what I found dotnet/roslyn#16109

/cc @CyrusNajmabadi

[vasily-kirichenko]

@gmpl dotTrace shows empty window after opening your snapshot :(

[cartermp]

Nice find @vasily-kirichenko.

[gusty]

Strange, I will try to capture it and upload it again.
@vasily-kirichenko regarding your finding I wonder why it fails only in my computer?

[slang25]

@vasily-kirichenko I had to update to the latest version of dotTrace to view the snapshot (previously throws an exception on opening), it now works for me

[gusty]

I tried installing VS2017 RC2 in my son's computer (very fast, gaming computer) and everything works fine there.
Even though, I managed to appreciate the time it takes to colorize the source file and there was no blocked UI during that process.

So, I don't know why is affecting only my computer. Maybe I should re-install VS2017 RC2 and see if the issue disappears.

[cartermp]

@gmpl Interesting. Hopefully it's just something strange with your install. I've also tried this out on my laptop (Macbook Pro 2015, so it's powerful, but not as powerful as my desktop) can't repro this on it either. Maybe I can find an older laptop around the office and try it out there...

[gusty]

@cartermp I have also a Macbook pro, but 2013.
Are you also running it under VMWare?
I forgot to mention that detail.

[gusty]

Yes, can you point me to a C#/VB file that is likely to reproduce this issue?

[forki]

I assume you would need to generate one

[vasily-kirichenko]

I've no idea. Assuming that the size of file plays role in freezes, peek any large file in VFT solution.

[vladima]

C#/VB parser are incremental so I don't think you'll observe any delays there.

[vasily-kirichenko]

@vladima I've added logging (see above), AddSyntacticClassificationsAsync almost always takes < 1 ms.

[vasily-kirichenko]

@vladima AddSyntacticClassificationsAsync uses the lexer only and caches the results. I cannot see why it can be slow at all.

[Pilchie]

If you have built Roslyn, then Binaries\Obj\CSharpCodeAnalysis\Debug\Syntax.xml.Internal.Generated.cs is 51,423 lines long.

[gusty]

I tried with long C# files.
The situation seems to be much better with C# but I still notice some very short UI freezes when working with very long files.
The files are long and the freeze is less than a second, whereas in the F# scenario I'm talking about shorter files and greater than a second.
I'm not an expert in the domain but I think the UI should never be blocked, all calls should be asynchronous, without exceptions, since what is fast in one scenario can be slow in another one.

[CyrusNajmabadi]

I'm not an expert in the domain but I think the UI should never be blocked,

This is definitely something we hear. However, there's a very real and serious concern that pushes back against that. Namely muscle memory. Specifically the desire from users that the same set of keystrokes always produces the same editor text result no matter what. For example, muscle memory is so ingrained in people that they fully expect and require that something like Con<dot>WL<openparen> always produce Console.WriteLine(. If we are not willing to block on the completion items being produced then you might end up with Con.WL( or Console.WL(. Both would be values that would trip up the user and force them to go back and fix things up.

This would also have the impact of making IntelliSense very untrustworthy. Instead of people being able to type, with a clear expectation of what they would get, people would have to continually review the results of intellisense all the time even if they were typing the same set of keystrokes.

--

As such, we have settled on a blocking-model* where we insist that CompletionItem computation be very fast. We have have spent an enormous amount of time in the Roslyn and TypeScript space optimizing item creation. Indeed, a large part of the design of our compilers is around doing the minimal amount of work necessary to get accurate results extremely quickly. That's because fast IntelliSense is so important to users and getting items quickly is necessary to provide them with a trustworthy model around editing.

--

• Note: for F# we added the non-blocking model. This was because it's not reasonable for us to insist that all language services come to the party already fast here. There are also interesting F# cases that can never ensure they'll be fast enough (i.e. TypeProviders). However, we want languages to opt-into being non-blocking, as that means that the experience their users will have will be one where they cannot ensure that completion will produce reliable results that they can have muscle memory dependency on.

[cartermp]

@gmpl Based on this discussion, it sounds like work to make FCS more performant (and the compiler, of course) is ultimately going to be our best course of action. I'm not sure if anyone has profiled FCS to see where the hot spots are for syntactic and semantic classfication for large files, but that would certainly be helpful.

[forki]

It's not like we're not constantly trying to make things faster... Am 10.01.2017 20:06 schrieb "Phillip Carter" <notifications@github.com>:

…

@gmpl <https://github.com/gmpl> Based on this discussion, it sounds like work to make FCS more performant (and the compiler, of course) is ultimately going to be our best course of action. I'm not sure if anyone has profiled FCS to see where the hot spots are for syntactic and semantic classfication for large files, but that would certainly be helpful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNPHEjk15CAwVlPkvKuIblahKxqSrks5rQ9azgaJpZM4LVd_j> .

[vasily-kirichenko]

I'm not sure if anyone has profiled FCS to see where the hot spots are for syntactic and semantic classfication for large files, but that would certainly be helpful.

We profile it many many times. The usual picture is that there is no obvious hot spots :(

About syntactic classification, it uses lexer, which is extremely fast, but it requires consistent state propagated from line 0 to shown code window (in order to properly handle multi line string literals). Once the cache is populated (when a document is opening), providing syntactic classification is nothing but array index access to get cached results for each line plus lexing changed (usually current single) line. All this is very very fast. I added logging into the classification provider and it returned results in sub-millisecond time. I've out of ideas why @gmpl experiences UI freezes.

[dsyme]

@vasily-kirichenko Is this still a known regression? Thanks

[vasily-kirichenko]

Yes, it's still reproduced on RC3. It should not on master, after my PR was merged (at least on non type provided code).

Looks like Roslyn asynchronous completion does not work.

[dsyme]

@vasily-kirichenko OK thanks. Do you think it deserves the "regression" label?

[vasily-kirichenko]

No. That's the way it's always worked I think, hasn't it? I mean completion blocks in VS 2015. Or not?

[forki]

I think the sync call is probably not a regression, but tbh the VS 2017 feels much much slower is nonresponsive in much more situations. So I would argue that overall typing experience definitely regressed. Am 28.01.2017 16:04 schrieb "Vasily Kirichenko" <notifications@github.com>:

…

No. That's the way it's always worked I think, hasn't it? I mean completion blocks in VS 2015. Or not? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNGNgKCjA8IrstFTJW56JR1ZfWEb7ks5rW1kUgaJpZM4LVd_j> .

[vasily-kirichenko]

VS 2017 feels much much slower is nonresponsive in much more situations

Could you be more concrete?

[forki]

That is "just" the feeling after parallel working with vs2015, vs2017 and ionide for while.

[vasily-kirichenko]

OK, we'll fix it.

[gusty]

I can confirm that RC3 still blocks my GUI. From a VS user perspective this is clearly a regression since in VS2015 I didn't have such GUI blocks.
@vasily-kirichenko Did you find a fix? If so, do you have a patch for RC3 I can use?

[vasily-kirichenko]

@gmpl build from master. That should give 1 second freeze max. If you want less, set VFT_GetFreshFileCheckResultsTimeoutMillis environment variable to something shorter.

[vasily-kirichenko]

I'm 100% sure it's fixed in RC4 + #2395

[gusty]

Thanks @vasily-kirichenko I tried to build it but I get an error in the process. If you have it built already and you can share it would be much appreciated.

[vasily-kirichenko]

@gmpl https://drive.google.com/open?id=0B8HLQUKik9VtMlV0TkNZU3M0VlU
You need RC4 and read this thread about how to install open source VSIX on it #2409

[gusty]

I tried it, looks like scroll still freezes when opening the file for the first time, but once it stops freezing it never freezes again.
When editing it freezes as always, but it seems to be no longer than 1 second as you mentioned.

[saul]

This can be closed now