MSVC2005 std::_Iterator_base:: functions slow while debugging

I'm profiling debug build c++ code in MSVC 2005 and certain code takes an extremely long time to execute (30+ seconds) compared to (1-2 seconds) in release.

I've set _SECURE_SCL to 0 in the compiler options (/D _SECURE_SCL=0) and verified its set to zero in the source.

I've copied the top consumers from the profiler (AMD CodeAnalyst)

• std::_Iterator_base:开发者_运维问答:_Orphan_me 19.74
• std::_Iterator_base::_Adopt 9.57
• std::_Iterator_base::operator= 8.98
• std::_Iterator_base::~_Iterator_base 8.55
• std::_Iterator_base::_Iterator_base 7.37

Trying to debug code and having to wait 30+ seconds each time kinda sucks, is there something I'm missing here?

UPDATE: Wrapping #pragma optimize() around the class method didn't do much but defining /D _HAS_ITERATOR_DEBUGGING=0 brought it down to release speed, these are now my top profiler hits (This seems normal for the function):

• std::_Vector_const_iterator >::operator++ 29.79
• std::_Vector_const_iterator >::operator++ 26.26
• std::_Vector_const_iterator >::operator* 25.74

3 functions, 60 instructions, Total: 2666 samples, 81.78% of shown samples, 2.76% of total session samples

Thanks for the fast replies!

You should also disable _HAS_ITERATOR_DEBUGGING if you care about debug performance. When iterator debugging is enabled, a lot of bookkeeping is done to help you to detect bugs in your code where you use an invalidated iterator or fail to correctly manage container and iterator lifetimes.

That said, a 30:1 performance difference between a checked debug build and an optimized release build sounds quite typical and reasonable.

Have a look at a few of the answers here: How to make MSVC debug builds run faster.

In addition to the _HAS_ITERATOR_DEBUGGING = 0 as mentioned by @James, it seems there's a neat trick toggling #pragma optimize("", off) / #pragma optimize("", on) to disable optimisation for single functions/blocks of code etc. If you only want to debug inside a particular piece of code, disabling the optimisation for just that piece might be significantly faster than turning optimisations off globally.

Hope this helps.