Friday, April 13, 2012 8:23 PM
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.
Edit: I am on Windows 7 Home Premium 32-bit, SP1
Edit again: I am using native c++
- Edited by LevyDee Friday, April 13, 2012 10:38 PM
Friday, April 13, 2012 8:41 PM
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.
Friday, April 13, 2012 9:15 PM
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
- Edited by MaybeCompletelyW Friday, April 13, 2012 9:31 PM second sentence
Friday, April 13, 2012 10:37 PM
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
Saturday, April 14, 2012 4:39 AM
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.
- Proposed As Answer by Jack Zhai - MSFTMicrosoft Contingent Staff, Moderator Thursday, April 19, 2012 2:35 AM
- Marked As Answer by Jack Zhai - MSFTMicrosoft Contingent Staff, Moderator Monday, April 23, 2012 4:59 AM