[puetzk]

It's because it's trivial to improve. The reason the MSVC STL is so slow in debug mode, is because it's really debug; they pull out all the stops to bounds-check every dereference, keep a generational count to detect iterators that could potentially have been invalidated by an operation that moved elements or reallocates the container (and do so whether or not the potential resize actually happened), etc. This adds a ton of code to the iterator paths, and (due to that code size) loses most inlining opportunities.

If you want it to be as fast as other implementations, ask it to do less of this. They provide [_ITERATOR_DEBUG_LEVEL](https://docs.microsoft.com/en-us/cpp/standard-library/iterat...) for exactly that purpose. I think their choice of default (Debug means you want it to catch as many bugs as it can, and Release means it should be fast) is appropriate.

If they hadn't provided the knob to adjust this I'd agree they had a problem for some use-cases, but if you want the faster-but-less-thorough mode you just have to ask for it.

[gpderetta]

As you explained, the debugging mode for STL is well beyond normal debugging mode (i.e. no optimiziations, all debug symbols). It explicitly changes complexity guarantees of the stl to catch issues with iterator invalidation and other nasty bugs. As such it adds a considerable runtime cost to any use of the STL.

In a way it is comparable to the overhead of the sanitizers available in other compilers.

IIRC MS chose to enable it by default in debug mode as part of their effort of fortifying unsafe C and C++ code against security bugs, but of course it has a large penalty.

libstdc++ has a similar debug mode, but it is disabled by default, as, in addition to be more expensive, it also breaks the ABI.