4 ms·

C++ is relatively fast but MSVC’s STL library’s debug performance is abysmal. It’s been like this since at least MSVC 2008 too. I’m not sure why Microsoft doe

C++ is relatively fast but MSVC’s STL library’s debug performance is abysmal. It’s been like this since at least MSVC 2008 too. I’m not sure why Microsoft doesn’t think it’s a priority to improve.

wolfgke 8y ago
> C++ is relatively fast but MSVC’s STL library’s debug performance is abysmal. It’s been like this since at least MSVC 2008 too. I’m not sure why Microsoft doesn’t think it’s a priority to improve. If you want fast performance, you use a Release build. The purpose of a Debug build is that you can detect the source of as many bugs in your program as possible. So for Release build, it is a priority to improve performance (and in my opinion Microsoft did a good job). For the Debug build, it is a priority to improve the detectability of bugs in your program. Here also in my opinion Microsoft did a good job.
- svdree 8y ago
  That sounds reasonable, until you have to debug an issue that only manifests itself when working with a huge dataset, in which case the whole thing becomes pretty much unusable. As the article says, debug mode is expected to be slower, but the difference between MSVC and the other 2 is just crazy.
  - MauranKilom 8y ago
    It's crazy because the knob for "how much debugging do I want to do" (aka iterator debug level) has been left untouched. Do you want the most rigorous checks (the default)? Don't do anything. Just want to avoid "variable optimized out" while debugging? Turn iterator debug level to "none".
puetzk 8y ago
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/iterator-debug-level?view=vs-2017 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 8y ago
  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.
deleted 8y ago
[deleted]

wolfgke 8y ago

> C++ is relatively fast but MSVC’s STL library’s debug performance is abysmal. It’s been like this since at least MSVC 2008 too. I’m not sure why Microsoft doesn’t think it’s a priority to improve. If you want fast performance, you use a Release build. The purpose of a Debug build is that you can detect the source of as many bugs in your program as possible. So for Release build, it is a priority to improve performance (and in my opinion Microsoft did a good job). For the Debug build, it is a priority to improve the detectability of bugs in your program. Here also in my opinion Microsoft did a good job.

svdree 8y ago
That sounds reasonable, until you have to debug an issue that only manifests itself when working with a huge dataset, in which case the whole thing becomes pretty much unusable. As the article says, debug mode is expected to be slower, but the difference between MSVC and the other 2 is just crazy.
- MauranKilom 8y ago
  It's crazy because the knob for "how much debugging do I want to do" (aka iterator debug level) has been left untouched. Do you want the most rigorous checks (the default)? Don't do anything. Just want to avoid "variable optimized out" while debugging? Turn iterator debug level to "none".

puetzk 8y ago

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/iterator-debug-level?view=vs-2017 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 8y ago
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.

deleted 8y ago

[deleted]