Yes, that’s what I mean. And before you say ”debug performance doesn’t matter”: yes it does. I work in gamedev and it’s a huge problem that C++ has such awful debug performance, because it’s hard to debug a game if it’s running in single-digit framerates. It’s a large part of the reason why EASTL is so popular in gamedev.

I feel like that's mostly Microsoft's fault, their STL implementation is super aggressive about checks in debug builds to the point that it becomes sort of useless in heavy use/high performance scenarios. Between that and the lack of valgrind, I'm pretty glad I left that world.

Over in Linux/g++ land, it's not nearly so bad. Bounds errors are mostly handled by address sanitizer such that -O0 performance is decent. And if -O0 is too slow, there's -Og which takes slightly longer to compile and has less information for gdb.

I work almost exclusively in "g++ -O0" until it's time to release.

Clang is decent too, but I find the C++ compile times are atrocious, like almost double for my admittedly template-heavy code. And performance of the compiled output is no better.

You could use ITERATOR_DEBUG_LEVEL=1 or 0 in debug mode; I made a "FastDebug" profile for this, although you will have to recompile dependencies

Doesn't gcc have -Og that enables some optimizations but leaves the ones that prevent debugging.

It has issues sometimes evaluating inlined expressions, unfortunately.

> single-digit framerates

In more explicit terms-- you are a soft-realtime app developer trying to live in a world that rarely measures performance or even writes specs with your constraints in mind.

I wish you game devs would harp on this more. I'm just a lowly soft-realtime audio software dev. My voice doesn't carry because there aren't mountains of cash behind me to help echo it.

oh it's been harped on for years. But people with mountains of cash already wrote their own STL and heap allocators :-) Those are usually your main bottlenecks in usability of debug builds.

I've worked on games with "DebugOptimized" builds where it's optimized,but instrumented in other ways. That's probably the best solution. You only drop down to full debug if you absolutely can't debug a specific issue in an optimized build.

With Visual C++, if you are careful you can build a version with release runtimes and third party libs so only your code is debug. Microsoft makes it harder than it has to be though.

Why not use a debug release build. Like O1 with debug symbols.

We absolutely do, but it’s significantly harder to debug. Functions are inlined, variables are eliminated, loops unrolled, etc.

But yeah, very often it’s basically the only option, running an optimized build with debug symbols. This is why it’s such a problem with C++: debug builds are frequently pointless because the performance is so bad, which makes debugging a lot harder.

Yeah that makes sense. There's no good alternative in C++, thanks to the mess created by all the zero-cost abstractions that are very much not zero-cost without a the optimizations of a release build.

Single-level inlining helps a lot with that but any libraries that do more calls that should be inlined are still a pain (and it reduces your debugging ability with, say, lambdas in VS at least).