How to stop visual studio using debug free

My application needs to free a very large hash table, and it is incredibly slow in debug mode, so slow that I can not realistically work with it...but in release mode I have no debug symbols at all.. I need to debug the executable and understand I should be able to get it to link with release versions of the crt libraries. I have done this by changing my "code generation" options to use "multithreaded dll" rather than "multithreaded debug dll", however when I开发者_如何学JAVA put a breakpoint in my hash table free routine and follow it through to the actual free call, it is using a function in a debug dll.

Anything else I can try? Is it a better option to work with the release configuration and try and get that to generate symbols for the stuff I actually need to debug?

(vs 2010 btw)

You can have debug symbols despite using release CRT and having all the optimizations turned-on. In fact this is what Visual C++ defaults to in Release configuration (see the Project Properties / Configuration Properties / C/C++ / General / Debug Information Format; and Linker / Debugging / Generate Debug Info). Please note that optimized code might be harder to debug - order of instructions may be changed and some pieces may be optimized-away entirely, causing some unexpected behavior when stepping through the code.

BTW, to turn-off the debug CRT, it is not enough to just change "Multi-threaded Debug DLL (/MDd)" to "Multi-threaded DLL (/MD)", you also need to remove _DEBUG from Preprocessor Definitions.

That being said, the slowness you are experiencing may not be the consequence of your program at all - this may a debugger artifact (i.e. the slowness of reading large data structures for the purpose of displaying them in debugger UI). Please try running your program (Debug or Release configuration - it does not matter much) outside debugger and see if this makes a difference.

If so, and you can't make your hash table smaller just for the purpose of debugging, you'll have to either resort to "printf debugging" (i.e. manually insert diagnostics) or possibly try the remote debugging.

Add this at the start of stdafx.h or define it as a pre-processor macro for your debug build:

#define _SECURE_SCL 0

It will cause the following to happen, making your code run faster in debug mode:

All standard iterators are unchecked (iterators can move beyond the container boundaries, leading to undefined behavior). The unchecked form of a function will be used, for standard functions with checked forms (see list below).

If an output iterator is a checked iterator:

• You will get checked behavior on calls to the standard function (std::copy, for example).
• You will get checked behavior on calls to a checked function (stdext::checked_copy, for example).
• You will get checked behavior on calls to an unchecked function (stdext::unchecked_copy, for example).

If an output iterator is an unchecked iterator:

• You will get unchecked behavior on calls to the standard function (std::copy, for example).
• Calls to a checked function (stdext::checked_copy, for example) will result in compiler warnings.
• You will get unchecked behavior on calls to an unchecked function (stdext::unchecked_copy, for example).

You can read more about this behavior in the Checked Iterators section of MSDN. Normally, you want checked iterators to be turned on for Debug builds, but there are certain applications that perform a lof of operations in a short period of time where they can become a nuisance.