Visual studio slowing down application

Question

This is kind of a vague question, but is there anything I can do about visual studio slowing down an application? If I run the executables outside of visual studio it runs at a very acceptable speed. If I run it inside visual studio with the debugger enabled it runs nearly 200x slower. I have tried to uninstall and reinstall visual studio to no avail. I removed all my plugins (ants & resharper) and still nothing. I have ran the project inside a visual studio on another computer and it the speed was normal. What can I do to resolve this? It seems to have happened recently, but potentially gradually.

Update: I have ran it now in other visual studios, and the slowdown maintains. My only conclusion is the way im allocating memory in the speeds that I am in the application is causing the debugger to slow things down in some way. Anyone ever have any experience in this happening?

Answer 1

Are you pulling down symbols from a symbol server? That's a common cause of slowdown.

Check _NT_SYMBOL_PATH if it is set, or your debugging options if using VS 2008 +

Answer 2

In general, the Visual Studio debugger doesn't slow things down. This must be something specific to your application.

For instance, there's a recent question on SO from someone who is getting an OutOfMemoryException when debugging but not when running outside the debugger. It appears this is due to the way he's allocating memory - the technique is sensitive to the number of assemblies loaded into memory. Most programs would not be sensitive to this passive effect of the debugger. Maybe you also are suffering from some effect related to the debugger, yet not completely the debugger's "fault".

---

Mitch Wheat suggested you might be running a virus scanner. That reminded me of a similar piece of software that took it upon itself to pay attention to Visual Studio loading and unloading assemblies. This was a piece of VPN software that provided "endpoint security". It was meant to check what programs you were running while connected to the VPN and to make sure they met the security policy. This meant being informed of every assembly that loaded.

Visual Studio loads and unloads a lot of assemblies. This VPN software was so interested in that fact that it actually caused a BSOD - the only time I've seen an application cause a BSOD - because it installed a file system filter or some such, and was being notified in Kernel mode. That plus a bug of some sort was enough to bring the system down.

So, in general, look for some piece of software that cares what's running on your computer. Maybe "endpoint security", maybe a virus scanner, maybe a search indexer, or whatever.

Answer 3

The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.

You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1

This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived: http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx

Answer 4

Exceptions are very expensive when running within the debugger and can slow down the application if many are thrown and caught. Have a look at the Output window of Visual Studio where you can see the thrown exceptions.

Answer 5

The VS debugger adds to your code additional commands in order to allow all the functionality it brings. The drawback can be slowing down your application.

Perhaps this is the reason why your app works fine when you run the executable on another computer.

Then this is a problem that should not bother you, becouse the release version of the application matters - who cares about the performance of debug version if the final one works well.