STL too slow in debug mode

On which compiler/toolchain?

Define _SCL_SECURE and _HAS_ITERATOR_DEBUGGING as 0. Still, it'd be a good idea to test with them on from time to time, because they add extra error checks and can catch problems that rarely crop up in release builds.

Quote:

Original post by Blobberson In my current project, I'm using std::list, and everything works great and fast in release mode, but in debug mode my framerate drops to below 10. Is there a way I can disable all the debug calls/bound checks/data/etc. for STL while keeping it intact for the rest of my program?

Yes. make a release build. [grin]

Why is it a problem that your framerate drops below 10? What was it otherwise, and why isn't <10 acceptable?

And also, are you sure std::list is the best data structure to use? std::vector or std::deque are often better, even if you need a datastructure with "list-like" properties.

Anyway, there are two things in particular I can imagine would may affect STL performance. STL code tends to rely heavily on compiler inlining, so if that is disabled, you'll see a noticeable drop in performance. And other than that, the NDEBUG is the "standard" way to denote a release build, which means asserts and other debug only code will be removed.

On MSVC, there are some additional macros to control how many debug checks are performed. In particular, _SECURE_SCL = 0 and _HAS_ITERATOR_DEBUGGING = 0 maybe worth using. (the former applies to both debug and release builds. The latter is only enabled by default in debug builds, so shouldn't be necessary for release)

Creating a fast debug build is a valid request and one of the reasons EA created EASTL IIRC.
I think either Zahlman or SiCrane made a post about 2 months ago which showed how to disable more than has already been said in this thread, someone may have a bookmark of the thread.

Thanks for the help everyone, I've got it running up to 30 FPS in debug mode now using _SECURE_SCL = 0 and _HAS_ITERATOR_DEBUGGING = 0, which is adequate. Though any extra optimizations like those are still welcome.

Quote:

I think either Zahlman or SiCrane made a post about 2 months ago which showed how to disable more than has already been said in this thread, someone may have a bookmark of the thread.

I elaborated on this as well.

Quote:

In my current project, I'm using std::list, and everything works great and fast in release mode, but in debug mode my framerate drops to below 10.

The first question to ask would be why are you using list in a performance sensitive part of code? If you don't modify it, then using continuous storage would yield better performance. And if you are modifying it, then you'll be trashing heap memory.

Also, what are your expectations of a debug build? Which features would you consider important? Debug mode as such doesn't exist, it's just a collection of compiler and linker settings. Out of those, which would you select?

It's important to understand that just turning off everything is essentially the same as using release configuration, thereby invalidating the purpose of debug build. Some settings also complicate debugging since they desync assembly and source, remove debugging symbols or do not perform some run-time checks which can detect buffer overruns, numeric overflows or other trivial problems.

I'm really not sure why everyone is jumping on the OP so much. His request is perfectly valid, and I don't have too many problems imagining what he wants. (It sounds like he's got it, too). If I were him, I'd want a build that has compiler optimizations disabled (-O0), has asserts, and has debugging symbols defined. The first and last of those are the two critical pieces that enable actually debugging code (because expressions won't be optimized, and intermediate values will get written to the stack). Having asserts is just good common sense.

Finally, having a playable frame rate is really critical. If your debuggable build runs like crap, then no one on the team ever wants to run it, and everyone uses release build. Then when things break, you're screwed, because you can't debug. If the only thing you have to sacrifice to get a playable debug build is STL iterator bounds checking ... it's a no brainer.