Visual F# Power Tools is unbearably slow and even blocks the Visual Studio UI

[exercitusvir]

I have a small solution (1 medium-sized project and 6 tiny projects) and Visual F# Power Tools makes working in Visual Studio unbearably slow. It even regularly causes Visual Studio 2013 to "not respond". It's already bad enough that it takes about 5-20s to see the result of updates, but blocking the UI is completely unacceptable. I can't imaging using it on large projects or solutions now.

You should make sure that absolutely everything is running asynchronously. It seems that some background tasks are running right in the UI thread. It's okay if some things just take longer to update, but Visual F# Power Tools should not slow down my typing.

I've used Visual F# Power Tools since it came out and it's amazing, but it's gotten so slow that I had to disable it. I hope you can fix these performance issues before adding more features.

[vasily-kirichenko]

Please, review the code and tell us where we do intensive computations in the UI thread. Then we will think what to do with that.

[exercitusvir]

Which code do you mean?

[vasily-kirichenko]

You should make sure that absolutely everything is running asynchronously.

This one.

[vasily-kirichenko]

Talking seriously, VFPT is fast enough to make the maintainers' daily job comfortable. That's it. If it's unusable for you for some reasons (you may work on really large solutions (like more than 200 projects), or you may run VS in a VM or on an old hardware), I'm afraid it's you and only you who can make the addin faster.

[dungpa]

@exercitusvir What version of VFPT are you using? AFAIK v1.9.0 has incorporated a lot of optimizations to move computations away from UI thread.

You can profile the extension and recognize what slows down your particular use case. We would be happy to incorporate further optimizations, but we would like to know where things go wrong first.

[exercitusvir]

@vasily-kirichenko As I said, it's 1 medium-sized project and 6 tiny projects (no 200). I am also not running it in a VM and not using old hardware.

It's kind of hard for an outsider to diagnose these kinds of issues. But the fact that the UI thread is blocked means that there must be work being done on the UI thread that should not be done there. I have no more performance issues since disabling VFPT. In fact, VS feels like a text editor in terms of speed now (and in terms of functionality without VFPT). I really like VFPT and I was not trying to disrespect your work.

@dungpa I was already using v1.9.0. Thanks for asking though.

[vasily-kirichenko]

@exercitusvir Can you suggest a strategy to identify what code still runs in the UI thread?

[exercitusvir]

I am not sure. It did not even happen consistently. Just most of the time. Restarting Visual Studio sometimes helped for a while. But I noticed that it this always happened when I changed text (code or comments) in a project that uses explicit member constraints on statically resolved type parameters that are fulfilled by a class with overloaded static members. This is done to retroactively implement a function on existing types to get something similar to type classes. I guess this is uncommon in F# so you might not experience this in ordinary projects.

[asik]

This may be related to known performance bug on the F# compiler (dotnet/fsharp#343) .

[dungpa]

@asik Yes, definitely.

@exercitusvir To be honest, if you use explicit member constraints extensively, you're out of luck. In the end, we still use F# compiler to do type checking. It can take forever or has abysmal behaviours for such programs.

You can disable all features that always run on code changes (see http://fsprojects.github.io/VisualFSharpPowerTools/faq.html#VFPT-is-slow-what-can-I-do-to-speed-it-up) and enable those that are acceptable to your scenarios. You can comments on dotnet/fsharp#343 to raise awareness about this issue.

[vasily-kirichenko]

Unfortunately, I gave up using FSharp.Plus and FsControl because VFPT was unusable. It's definitely the compiler issue.

[exercitusvir]

Thanks for the information. I am not using FSharp.Plus or FsControl directly, but my approach is very similar, so I've added a comment to that issue to raise awareness.

Even if this is currently an issue of the F# compiler, why does it have it lock up the UI if everything is asynchronous? The UI never freezes when I have VFPT disabled. It would be better if VFPT did not lock up the UI and instead just took a long time to update.

[exercitusvir]

@dungpa Thanks for the suggestion. I'll try to disable all and re-enable each feature one by one to narrow down the feature that causes this.

[drvink]

Unfortunately this issue is not limited to VFPT; you will see the same behavior when using e.g. Emacs and fsharp-mode, assuming we are talking about dotnet/fsharp#343

[theor]

Did some profiling: http://i.imgur.com/8yeYBx4.png Full dottrace here : https://drive.google.com/file/d/0B8m8OpReqlmHQVdXSFZWZElTUGM/view?usp=sharing

So in my case, definitely the Resolve namespaces feature.

[iccfish]

I'm running into the same issue. And this issue doesnot only effects F# projects but also with other projects(such as c#).
Everytime I change the configuration of current project (such change from Debug to Release), Visual Studio hangs up for a long time (almost 20~40secs). This problem troubles me for a long long time, and for a long time I think this was due to other extensions like R#.
Today after doing some profile, I finally found that this issue was due to VFPT....Can't believe it. Because my projects were not F# projects so I never thought there will be realtions.

After I disable VFPT this issue solved...

[vasily-kirichenko]

@iccfish we removed ClearLanguageServiceRootCachesAndCollectAndFinalizeAllTransients call two months ago #1076

Try to install the addin built from current master, you can get it here https://ci.appveyor.com/project/dungpa/visualfsharppowertools/build/artifacts

[vasily-kirichenko]

If you still experience the issue on current master, reopen this issue or create a new one.