VS 2017 - Very slow (laggy) when debugging

问题:

When I debug my solution, vs 2017 is very laggy and slow it's like it has to operate something heavy in the background.

So it stops "responding" every 5 seconds for 2 seconds, which is very annoying. Any suggestions?

EDIT (tried suggestions):

• Browser Link is turned off
• Stopped customer feedback

回答1:

After some additional investigation I found this thread Unchecking Enable Diagnostic Tools while debugging in Tools → Options → Debugging → General did the trick!

Unchecking Enable JavaScript debugging for ASP.NET in
Tools → Options → Debugging → General
makes a huge difference in performance.

回答2:

If disable Diagnostic Tools don't fix the problem try to disable IntelliTrace, Unchecking Enable IntelliTrace, in Tools -> Options -> IntelliTrace. Work for me.

回答3:

I have tried disabling few things myself just to see what is causing it. The only thing that did work for me is Tools > Options > Debugging > General > "Enable JavaScript debugging for ASP.NET (Chrome and IE)".

I'm using VS2017 Enterprise v15.2 for Asp.net WebForms.

回答4:

I also experience the lag when "Enable Javascript debugging for ASP.NET (Chrome and IE)" is checked. And Turning off the "Enable Diagnostic Tools while debugging" did not help.

However, I also noticed that when I F12 for Chrome Developer Tools, then lag time goes away and the app performs.

Hope this helps.

回答5:

Hiding the Threads window did the trick for me.

回答6:

Only one thing that helped me was disabling Debugger option of Resharper. If you use Resharper, try to UNCHECK "Show local variables values in editor" in menu: Resharper -> Options -> Tools -> Debugger.

It helped for me.

回答7:

What worked for me was removing all the following folders in the solution's directory:

• .vs
• x64
• Debug
• Release

回答8:

I experienced same problem. In debug mode, my webforms project ran very slowly. When using Ctrl+ F5, it ran quickly (as it does when deployed). I found a try/catch block that was executing 45 times. It wasn't doing anything, it was just trapping an error that I had made. I fixed the error and, when removing the try-catch block - voila! -- back to full speed.

So if you're experiencing this problem and you've tried all the solutions above (I did), look for a try catch block that is firing often. [ Fix your error :) ] and then remove the try-catch block. I can't believe the difference it has made. Shouldn't have made any difference at all, of course, since the try-catch block wasn't doing anything, but it did.

回答9:

I gave up getting Debug=>Attach To Process working... even tried ALL the solutions on this SO post (2-pages worth).

Solution

Use ReAttach VS IDE Extension. This bypasses the need to ever use the Attach to Process dialog again if it's a process you've recently attached to.

回答10:

If you are using VS 2017 Enterprise edition, try disable IntelliTrace feature (Tools -> Options -> IntelliTrace)

with this feature turned off, the laggy behavior went away even keeping the Diagnostic tools turned on (Tools -> Options -> Debugging -> Enable Diagnostic Tools while debugging)

回答11:

Sometimes it is because of a Realtime scan in Antivirus.

"Add exceptions" Visual Studio files/folders for your Antivirus

C: \ Program Files (x86) \ Microsoft Visual Studio \ 2017 \ Professional \ Common7 \ IDE \ devenv.exe

C: \ Program Files (x86) \ Microsoft Visual Studio \ 201

回答12:

I had this problem where the program was running slower if started from visual studio, turned out to be too many threads, like alot of new System.Threading.Thread() in a loop etc. I switched the code to use the ThreadPool instead with Task etc and the slowness went away.

回答13:

choosing "Load only specified modules" did the trick (Tools=>Options=>Debugging=>Symbols)

回答14:

I also had this problem, for me helped disabling Enable Edit and Continue options in Tools → Options → Debugging → General.

回答15:

workaround that I used was to run msvcmon.exe locally with admin mode before starting the debugger. Then start the attach window and providing the remote debugging port.