Reputation: 4359

Debugging sometimes very slow

I'm using VS2008, in a normal mid-size solution.

Sometimes, debug stepping becomes very slow. A padlock gets rendered on the every file tab for every "step" (F10/F11), and it can take up to two seconds for every step. That makes debugging very annoying and slow. Has anyone seen this problem?

Upvotes: 13

Answers (17)

Igor Brejc

Reputation: 18994

Try turning off the "Enable property evaluation…” setting in Debugger options, it should make debugging much faster (read more: Fix: Make Debugging Faster with Visual Studio):

_{(source: flickr.com)}

Upvotes: 12

baronvonmike

Reputation: 11

Disable “Show Threads in Source” if it is enabled, and also close the Parallel Stacks Threads, Tasks, and GPU threads windows if it they are open. Those cause the debugger to walk the call stack for every thread in the process.

Upvotes: 1

Pavel P

Reputation: 16843

Accepted answer is hardly relevant or helpful!

These are some possible issues that could make debugging extremely slow:

"Show threads in source" (see screensht). If you have a heavily mutithreaded app you won't be able to debug with this option enabled. What this options does is it tries to show in the same file execution position of other threads if they also execute the same code. So, if you have many threads debugger needs to check for all threads where they are located. If you have many threads this might make each step with debugger extremely slow.
Many conditional or even regular breakpoints. Especially if these are in some inline functions of some header file.
"Show external code" enabled in call stack also makes it slower.

Upvotes: 1

bvgheluwe

Reputation: 853

If you have a virus scanner (with realtime scans enabled), check if C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe* is excluded from the scan.

In my case, debugging became very slow after the companywide rollout of new virus scanner. After a while, we found out that the realtime scan of msvsmon.exe was the culprit.

*modify path as per your installation folder

Upvotes: 0

Tommy Demers

Reputation: 13

I had the same problem, I deleted all my variable watches and it helped a lot! Because each step during debug, it reloads all watches and it takes time...

Solution : From the Debug menu, choose Windows, then Watch, and click on Watch1, Watch2, Watch3, or Watch4. The menu will appear and right click on them to clear them all.

Upvotes: 0

Loren Paulsen

Reputation: 9378

I experienced this problem after enabling ".NET Framework source stepping". Stepping got a lot faster after turning this off. In particular, turning back on "Enable Just My Code" (Options > Debugging > General) removed about half the lag I was experiencing.

The other half was caused by loading more Symbols than I needed (Options > Debugging > Symbols). At one point I needed Symbol locations defined, but I didn't anymore, so I was able to uncheck them all and click "Empty Symbol Cache". If you have _NT_SYMBOL_PATH listed it means you have this environment setting defined, and Visual Studio won't let you uncheck it. You'll need to remove the setting. More about Symbol settings (https://blogs.msdn.microsoft.com/visualstudioalm/2015/01/05/understanding-symbol-files-and-visual-studios-symbol-settings/)

Upvotes: 0

Jason Honingford

Reputation: 598

What helped me was disabling Diagnostic Tools.

Tools / Options / Debugging / General / Enable Diagnostic Tools

Visual Studio 2015 (Version 14)

Upvotes: 0

areB

Reputation: 1

clear all entries in the watch window.

Upvotes: -1

babelchips

Reputation: 91

The "Show Threads in Source" suggestion did not help.

But I fixed it by enabling Tools:Options:Debugging:General - > "Require source files to exactly match the original version".

Mine was unchecked initially, but after changing it stepping through code in VS2008 is now back to normal speed.

Upvotes: 0

valerie

Reputation: 1111

Another cause of single step slowness is use of Intellitrace (available only in Ultimate). To turn it off, Tools | Options | IntelliTrace. Uncheck Enable IntelliTrace.

Upvotes: 0

Bruce Dawson

Reputation: 3474

There are many things that can cause Visual Studio to be slow. Excessive breakpoints and Show Threads in Source are probably the two most common, but you don't care what is most common, you care what is making Visual Studio slow for *you*.

So, if deleting breakpoints and turning off Show Threads in Source doesn't work then you need to profile Visual Studio. That lets you find performance problems that are unique to your situation. An explanation of how to do this (which resolved two separate Visual Studio performance problems) can be found here:

http://randomascii.wordpress.com/2013/03/03/visual-studio-single-step-performance-fixes/

More investigations of performance problems in other people's code are detailed here:

http://randomascii.wordpress.com/category/investigative-reporting/

Upvotes: 1

user2239903

Reputation: 41

I had the same issue, especially when debugging apps with many threads.

It was caused by the feature "Show threads in source".

See the following link for details:

Code Project: Show threads in source

Visual Studio Single Step Performance Fixes

After disabling this feature, problem has been fixed.

Upvotes: 3

zergusik

Reputation: 51

In addition to all issues mentioned above.

A "Disassembly" tab (opened in a background) slows down the debugging by 1-2 sec per step. (Not sure if it always happens like this).

Upvotes: 5

Muhammad Mubashir

Reputation: 1659

Disable Show Threads in Source in Visual Studio. and Close Call Stack Trace Window.

Disable Show Threads In Source. after Press debug Button

Upvotes: 7

user270739

Reputation:

I've noticed in VS 2008 that if you have the 'Show Threads in Source' button selected in the debug toolbar that stepping can be at least 10 times slower.

I've also noticed that if your application takes a long time to start in debug mode that this can be resolved if you simply 'Delete All Breakpoints' under the Debug menu. This solved an annoying problem for me even though I only had a handful of breakpoints set at the time.

Silas

Upvotes: 21

Michael Petrotta

Reputation: 60902

Here's a link to some guidance on Mike Stahl's MSDN blog, with respect to resolving debugger slowdowns

I ran across this because conditional breakpoints in my app's hotspot killed my debug performance. Personal BKM: resolve potential performance issues before you leave for the night, for you may not remember them in the morning.

Upvotes: 0

Brian

Reputation: 2221

Yes, Visual Studio is extremely slow at debugging at times. There are a number of additional steps (in addition to turning off the Enable property evaluation" setting) you can take to speed up the process. Essentially, it requires massive amounts of RAM, so performing a few things to free that up will help.

Go into the preferences of Visual Studio. Look for all the options relating to animating menus and so forth. These have a tendency to be intensive at times, while not specific to debugging as you usually aren't opening up menus, it does seem to help.
On the computer itself, if you right-click on my computer. Go to the advanced tab and under performance. If you adjust your computer for best performance it'll speed things up. It gets rid of any nice styles on your computer, but it'll free up some of the memory you are wanting.
Close any unnecessary programs. The more memory you can give Visual Studio the better it is going to behave.

Upvotes: 0

Debugging sometimes very slow

Answers (17)

Related Questions