Fsharp: 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 https://github.com/Microsoft/visualfsharp/issues/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 https://github.com/dotnet/roslyn/issues/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.

[cartermp]

Nope, using Parallels.

[cartermp]

@gmpl Have you had a chance to reinstall and try it out? I've been out for New Year's celebrations and haven't found an older laptop to install the tools on.

[vasily-kirichenko]

@cartermp just use VMWare, it slows down everything _a lot_.

[gusty]

@cartermp No, still trying to make disk space enough to be able to de-install re-install it.
But will try, this thing is bothering me a lot.

@vasily-kirichenko slows down but does it block?

[vasily-kirichenko]

@gmpl I haven't tried. That was my experience with VMWare in general.

[gusty]

@vasily-kirichenko yes, I would love to switch to Visual Studio for Mac, but at the moment it doesn't work for me, too many bugs.

[vasily-kirichenko]

@gmpl switch to windows instead.

[gusty]

Yes, but then I will have to buy a PC like the one my son has, but that costs money.
The other alternative is to keep optimizing the compiler, at the moment did better results than any new computer ;)

[vasily-kirichenko]

A great side effect of this is that the whole community is getting faster compiler :)

[vasily-kirichenko]

@gmpl could you try https://github.com/Microsoft/visualfsharp/pull/2158? The lexer cache was broken in master (maybe in RC2, too). It resulted with delays as you type code, scroll files and move caret around, especially on large files.

[gusty]

@vasily-kirichenko that's exactly what I am experiencing.

How can I try it? Can you possible point me to a step-by-step guide on how to build and test it?

Thanks in advance.

[forki]

step-by-step guide

that one should go to devguide

[vasily-kirichenko]

1. build.cmd vs
2. Run release\net40\bin\VisualFSharpOpenSource.vsix

Or you can download the VSIX I've just built from this PR https://drive.google.com/open?id=0B8HLQUKik9VtdncyMW4tS2NyWFE

[vasily-kirichenko]

It may not work properly (it does not on VFT solution for example, but works ok on other solutions).

To revert back to RC2 just go to Extensions and Updates and remove "Visual F# Tools" extension, then restart VS.

[gusty]

Thanks, will try it tonight when back home.

[gusty]

Hi all.
I tried the update and also tried re-installing VS2017.
Despite all efforts the issue persists.

[vasily-kirichenko]

I've tested the lexer fix PR on the huge TypeChecker.fs file and there were absolutely no freezes.

Maybe we should state something like non-virtualized Core i5 3GHz + 8GB RAM as a minimum system requirements?

[gusty]

@vasily-kirichenko I don't know what else can I do on my side. Did you have the chance to have a look at the dot-trace snapshot I sent? Does it help to spot the issue?

[vasily-kirichenko]

@gmpl oh, sorry, I forget about it. Will update dotTrace and examine it soon.

[vasily-kirichenko]

@gmpl OK, it's clear that it blocks UI thread when Roslyn calls our https://github.com/Microsoft/visualfsharp/blob/master/vsintegration/src/FSharp.Editor/Classification/ColorizationService.fs#L31 somewhere in Microsoft.CodeAnalysis.Editor.Implementation.Classification.SyntacticClassificationTaggerProvider+TagComputer.AddClassifiedSpansForCurrentTree(IEditorClassificationService, SnapshotSpan, Document, List), see https://github.com/dotnet/roslyn/issues/16109 again.

[gusty]

@vasily-kirichenko Yes, that seems to be the case. Unfortunately that issue is closed.

Now I'm between two worlds:
In VS2015 it worked fine but the F# compiler was so slow that at some point the UI was hit by all the resource it was consuming.
In VS2017 F# compiler works pretty fast but the UI get blocked by few seconds as I open new file or edit it.

I would like to have the best of both worlds: VS2015 with F# 4.1

[vasily-kirichenko]

@gmpl I've commented on that issue, please upvote.

[vasily-kirichenko]

@gmpl try this version https://drive.google.com/open?id=0B8HLQUKik9VtZUY5dUZhMWJzR2s

I moved the syntactic classification to the semantic one, which is async :) It's not the way to go for real, but if you confirm the UI freezes gone, we can push Roslyn team to call AddSyntacticClassificationsAsync asynchronously.

[forki]

But this would need to be done VERY soon.

Am 06.01.2017 4:48 nachm. schrieb "Vasily Kirichenko" <
[email protected]>:

@gmpl https://github.com/gmpl try this version
https://drive.google.com/open?id=0B8HLQUKik9VtZUY5dUZhMWJzR2s

I moved the syntactic classification to the semantic one, which is async
:) It's not the way to go for real, but if you confirm the UI freezes gone,
we can push Roslyn team to call AddSyntacticClassificationsAsync
asynchronously.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2104#issuecomment-270932403,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNGTEloYsU2hQJZKf6uC2WBj-q16dks5rPmJogaJpZM4LVd_j
.

[vasily-kirichenko]

The changes is here https://github.com/vasily-kirichenko/visualfsharp/commit/e0fd9173472aab0feaaf96e150ba7ce7451b542c if you interested.

[vasily-kirichenko]

@forki It's unlikely they will make such a dangerous change before RTM.

[gusty]

@vasily-kirichenko the link you sent me is a dot-trace snapshot

[vasily-kirichenko]

wow :) https://drive.google.com/open?id=0B8HLQUKik9VtVkZEdEVZM2NnWmM

[forki]

What wow?

Am 06.01.2017 19:02 schrieb "Vasily Kirichenko" [e-mail]:

wow :) https://drive.google.com/open?id=0B8HLQUKik9VtVkZEdEVZM2NnWmM

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2104#issuecomment-270963979,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNOdvsD-a3CFufZnwNsoGJBTzq-Zxks5rPoG6gaJpZM4LVd_j
.

[vasily-kirichenko]

@forki Posted the link to a wrong file...

[gusty]

This seems to solve the issue.
Now I can scroll while the code is still no colorized.
Then when typing there still seems to be some GUI blocks but waaay less than before, may be those are really related to the poor performance of my computer.
If they don't change the functionality to asynchronous, what are the consequences of leaving the code as you changed it, with the syntactic and the semantic in the same function? I know it will be an ugly workaround, but solves the issue.

[vasily-kirichenko]

@gmpl the consequence of leaving this code is that keywords will be colorized much, much slower as you type, especially on large files. There's (truly synchronous) AddLexicalClassifications method. I don't think it will work better that the AddSyntacticClassificationsAsync, but I will build a VSIX and you can test it, if you like.

[gusty]

@vasily-kirichenko I'll be happy to play with it.
And just in case they don't decide to change anything I'll keep your patches ;)
It's true that it takes more time to colorize but I don't care, I can stand it, but GUI block is really a no-go.

[forki]

So who would we need to ask about the roslyn method?

Am 06.01.2017 19:21 schrieb "Vasily Kirichenko" [e-mail]:

@gmpl https://github.com/gmpl the consequence of leaving this code is
that keywords will be colorized much, much slower, especially on large
files. There's (truly synchronous) AddLexicalClassifications method. I
don't think it will work better that the AddSyntacticClassificationsAsync,
but I will build a VSIX and you can test it, if you like.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2104#issuecomment-270968373,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNJUcjsv3_lveZD7DBn9svV3Nu3iuks5rPoZEgaJpZM4LVd_j
.

[vasily-kirichenko]

@forki the issue is here https://github.com/dotnet/roslyn/issues/16109

@Pilchie It seems it's necessary for F# that Roslyn calls AddSyntacticClassificationsAsync asynchronously. Do we have hope?

[forki]

Vasily that issue is closed.

Am 06.01.2017 19:28 schrieb "Vasily Kirichenko" [e-mail]:

@forki https://github.com/forki the issue is here dotnet/roslyn#16109
https://github.com/dotnet/roslyn/issues/16109

@Pilchie https://github.com/Pilchie It seems it's necessary for F# that
Roslyn calls AddSyntacticClassificationsAsync asynchronously. Do we have
hope?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2104#issuecomment-270969955,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNH_B_X9W3HEzWP2b1EkNzsGrMY89ks5rPofqgaJpZM4LVd_j
.

[vasily-kirichenko]

@gmpl Unfortunately, AddLexicalClassifications is not called at all. I've no idea why.

[vasily-kirichenko]

It seems it's called rarely and its results are considered as temporary, until parse tree is available. It looks like Roslyn always decides that we have the tree. Nevertheless, it's very unlikely this method could solve our problem.

[gusty]

I'll have to deinstall your patch :( because the FSI hangs, same happened with the previous patch you sent me. Hopefully they solve it for RC3.

[vasily-kirichenko]

Errors in FSI window on start?

[gusty]

Yes, probably because the FSI versions differs:

Microsoft (R) F# Interactive version 4.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

Session termination detected. Press Enter to restart.

unknown(1,1): error FS1225: File 'C:\Users\Gusty\AppData\Local\Microsoft\VisualStudio\15.0_37442e12\Extensions\ptcwwbq0.0gn\FSharp.Core.optdata' not found alongside FSharp.Core. File expected in C:\Users\Gusty\AppData\Local\Microsoft\VisualStudio\15.0_37442e12\Extensions\ptcwwbq0.0gn\FSharp.Core.optdata.

unknown(1,1): error FS0229: Error opening binary file 'C:\Users\Gusty\AppData\Local\Microsoft\VisualStudio\15.0_37442e12\Extensions\ptcwwbq0.0gn\FSharp.Core.dll': Exception of type 'Microsoft.FSharp.Compiler.ErrorLogger+StopProcessingExn' was thrown.

unknown(1,1): error FS3160: Problem reading assembly 'C:\Users\Gusty\AppData\Local\Microsoft\VisualStudio\15.0_37442e12\Extensions\ptcwwbq0.0gn\FSharp.Core.dll': Exception of type 'Microsoft.FSharp.Compiler.ErrorLogger+StopProcessingExn' was thrown.

[cartermp]

There's some good discussion going on in https://github.com/dotnet/roslyn/issues/16109 and it seems like we could address this. I'm tagging this for RTM since we can't have high minimum specs just to use F#.

[vasily-kirichenko]

@gmpl just copy FSharp.Core.sigdata and FSharp.Core.optdata into c:\Users\\AppData\Local\Microsoft\VisualStudio\15.0_d2a776e5\Extensions\Microsoft.VisualFSharpTools\Visual F# Tools\15.4.1.9055\

[gusty]

@cartermp I'm following that discussion and I agree with you, for me it seems to be just fine to use the patch from @vasily-kirichenko , but others might run into this problem and that would be really annoying, discouraging and also a regression if you consider previous behavior in VS2015.
Note that my computer is not that old, it's not the fastest because is not a desktop and is using VM but I'm sure this is not an uncommon scenario.

[vasily-kirichenko]

@gmpl please try this one https://drive.google.com/open?id=0B8HLQUKik9VtOC16YklSRldKeFk and share contents of Output window. I've added some profiling logging there, see https://github.com/Microsoft/visualfsharp/commit/5716001bc08ce1b9f0eb2365e0c011d5aa3bc061

[gusty]

Thanks @vasily-kirichenko
I installed it and this is the content of the output after opening Operators.fs :

[F#][INFO 10:15:59 AM] SyntacticClassification (lines 363..364): map [("defines", 0L); ("get data", 31L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 362..363): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 364..365): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 365..366): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 366..367): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 367..368): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 368..369): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 369..370): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 370..371): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 371..372): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 372..373): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 373..374): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 374..375): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 375..376): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 376..377): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 377..378): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 378..379): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 379..380): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 380..381): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 381..382): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 382..383): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 383..384): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:15:59 AM] SyntacticClassification (lines 384..385): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 363..364): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 362..363): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 364..365): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 365..366): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 366..367): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 367..368): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 368..369): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 369..370): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 370..371): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 371..372): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 372..373): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 373..374): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 374..375): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 375..376): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 376..377): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 377..378): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 378..379): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 379..380): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 380..381): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 381..382): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 382..383): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 383..384): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:00 AM] SyntacticClassification (lines 384..385): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:02 AM] SyntacticClassification (lines 363..364): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 362..363): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 364..365): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 365..366): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 366..367): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 367..368): map [("defines", 0L); ("get data", 0L); ("source text", 96L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 368..369): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 369..370): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:03 AM] SyntacticClassification (lines 370..371): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 371..372): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 372..373): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 373..374): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 374..375): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 375..376): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 376..377): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 377..378): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 378..379): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 379..380): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:04 AM] SyntacticClassification (lines 380..381): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 381..382): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 382..383): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 383..384): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 384..385): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 5..6): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 363..364): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 362..363): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 364..365): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:05 AM] SyntacticClassification (lines 365..366): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 366..367): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 367..368): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 368..369): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 369..370): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 370..371): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 371..372): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 372..373): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 373..374): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 374..375): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 375..376): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 376..377): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 377..378): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 378..379): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:06 AM] SyntacticClassification (lines 379..380): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:07 AM] SyntacticClassification (lines 380..381): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:07 AM] SyntacticClassification (lines 381..382): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:07 AM] SyntacticClassification (lines 382..383): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:07 AM] SyntacticClassification (lines 383..384): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:07 AM] SyntacticClassification (lines 384..385): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 363..364): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 362..363): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 364..365): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 365..366): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 366..367): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 367..368): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 368..369): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 369..370): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 370..371): map [("defines", 2L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 371..372): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 372..373): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 373..374): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 374..375): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 375..376): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 376..377): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 377..378): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 378..379): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 379..380): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 380..381): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 381..382): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 382..383): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 383..384): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 384..385): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]
[F#][INFO 10:16:18 AM] SyntacticClassification (lines 5..6): map [("defines", 0L); ("get data", 0L); ("source text", 0L)]

Let me know if you need more information.

[vasily-kirichenko]

@gmpl thanks. Were there UI freezes during this editing session? This log shows there were absolutely no delays on our side.

[gusty]

That was only opening the file without any other action so I can't tell you if there was UI freeze on that case.

But here's another log while scrolling and there were several UI freezes

And here's another one while typing, there were freezes as well but specially when I stop typing for let's say 3 seconds and attempt to start typing again.

[vasily-kirichenko]

Still no delays on our side :( I think it's just not enough CPU power for handling UI thread. Options are still as before:

• Roslyn should call AddSyntacticClassificationsAsync asynchronously
• We make AddSyntacticClassificationsAsync no-op and return all classification in AddSemanticClassificationsAsync

Roslyn team do not want to do #1 (for still unknown reason), the #2 is not good for most users :(

[gusty]

I think that means that I would experience those freezes with another language as well if the code file is large enough.

So that's another reason for them to make it async.

[vasily-kirichenko]

@gmpl Oh, that's a good idea to try to reproduce the freezes on C#/VB files. Could you try?

[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" [e-mail]:

@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
https://github.com/Microsoft/visualfsharp/issues/2104#issuecomment-271666883,
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" [e-mail]:

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
https://github.com/Microsoft/visualfsharp/issues/2104#issuecomment-275853138,
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 + https://github.com/Microsoft/visualfsharp/pull/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 https://github.com/Microsoft/visualfsharp/pull/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