In my Visual Studio, even I just wrote a single line of return in a C# console application, it will take me a minute after pressing F5 to execute the actual code (I mean the time it takes to stop on the single return statement after pressing F5 -- I set a breakpoint on return statement in Main function). I am wondering what is wrong? Any check list? Thanks!
I am using Visual Studio 2008 VSTS edition and debugging on Windows Server 2003 x64.
thanks in advance, George
From ScottGu's blog linked by Travis: "One other performance gotcha I've heard about recently is an issue that a few people have reported running into with the Google Toolbar add-in. For some reason this can sometimes cause long delays when attaching the Visual Studio debugger to the browser. If you are seeing long delays with your web application loading, and have the Google Toolbar (or other toolbars) installed, you might want to try uninstalling them to see if that is the cause of the issue."
A different cause plus... How to find the problem
To me it was the option ShowOtherThreadIpMarkers. A value =1 makes vs (2010) unbearably slow (3-5 secs for each debug step. With a value of 0 is fast again.
What is it that option? I have no idea. I could not find it through the vs user interface. I unchecked all possible debugging options in there and nothing worked.
So I went to Import Export Settings and loaded my old settings I've previously saved going backward in time until vs was fast again, then compared the vssettings files... etc, etc.
I'd like to remark that if you load the settings while you are in debug mode stopped on a breakpoint, they become effective immediately. You don't have to stop the debugger and restart.
Do you have a lot of breakpoints set? Those can really slow down startup time. Everytime a new module is loaded into the process address space, they all need to be checked to see if they are valid.
For me, the setting that killed performance (windows 8 even hanged except for mouse movement) was to UNCHECK "Break all processes when one process breaks" in Options -> Debugging -> General.
Hope this helps anyone.
You may need to delete all your breakpoints---note that you need to click the "delete all breakpoints" button (or use Ctrl-Shft-F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?).
If worst comes to worst, you may need to delete your
.suo
file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the.ncb
file as well.Just one more cause of a slow Visual Studio debugging experience...
Long time ago I enabled
FusionLog
to see what was causing an assembly binding problem.Make sure you disable it after using it. Why? Because it writes a lot of logging data to the disk while enabled.
This is the
FusionLog
key on Window's Registry [regedit.exe
]:Change
ForceLog
,LogImmersive
andLogResourseBindings
values from 1 enabled to 0 disabled.