Multi threaded program causes intermittent performance drop using Visual Studio debugger

Question

I recently refactored a program I have been working on for sometime, to make use of multiple threads. Shortly after, whenever running the program through Visual Studio 2010(F5), it will intermittently have terrible performance. But when I run the executable through the folder(not using visual studio), I never get this issue, not even once. I am curious if any one has any ideas what could be happening, and if there is an issue with my program, or with VS.

Thank you.

Edit: I am on Windows 7 Home Premium 32-bit, SP1

Edit again: I am using native c++

Answer 1

How aggressively does your application use the heap?  How often do you new/delete things or malloc/free things?  When running with F5 you are running using the debug heap.  When running with Ctrl+F5 you run normally.

Also, does your application log debug messages?  Visual studio can have a hard time keeping up with spam from OutputDebugString.

Also, do you create and destroy threads unnecessarily?  If you create and destroy threads very frequently then those messages will be logged and produce spam similarly to OutputDebugString.  Use a threadpool thread if this is your case.  (What language are you working in?)

Do you throw exceptions frequently?  First chance exception messages are logged in the output window too.

You can turn off tracking of any of the output window messages by right-clicking in the output window and un-checking messages such as:

• Thread Exit Messages  (in case you create and destroy too many threads -- but seriously, fix this with a threadpool)
• Program Output (in case you are getting OutputDebugString spam)
• Exception Messages (in case you have some code that throws, and handles, an exception)

If the heap is your problem, then you should make use of a memory pool.  Reuse frequently allocated objects, or merge objects whose lifetime is the same.

for example, if two objects A and B live for the same time, make a struct C with members A and B and just "new" and "delete" an object of type C.  Works great if there are hundreds of objects all with the same lifetime.  This often happens with serialization type tasks.

Answer 2

Also you may try to disable usage of debug-heap by setting _NO_DEBUG_HEAP environment variable to 1.
Though this will counteract in a certain sense the objectives of debugging.

With kind regards

Answer 3

I have 4 worker threads running, who's life span is that of the program. I am also not flooding the out put with debug strings, and not hitting first chance exceptions. I am a little concerned that I can run it just fine with out debugging(ctrl-f5) but have issues with debugging(f5).

Thanks for the input

Answer 4

Time to start measuring where the delays come from.

Sprinkle QueryPerformanceCounter calls around to see how long critical things are taking.  Try to isolate what code is taking a long time to execute.