Yep, looks like that’s this bullet point:
https://dhashe.com/category/blog.html#partition-your-tus-int...
This would be really unusual though right? For reference, in plain C code I see a 2x slowdown, in Zig a 4x slowdown (which I still need to investigate why exactly that's the case), and in C++ (even with heavy stdlib usage and on MSVC) at most 10x - which is the absolute worst case I've seen yet. My C++ info is a bit outdated though, have things gotten much worse in "modern" C++?
Or in other words: if you see a slowdown of 100x in debug mode, I would be really concerned about why the performance is so heavily dependent on the optimizer doing it's thing and would start investigating what's the reason for such a massive slowdown.
As far as I can tell, this is worse than for the average C++ codebase. I have some ideas for why the optimizer is able to achieve such large improvements with this particular code and some of that could surely be done with better source, but it's a huge code base and a refactoring on that scale just isn't going to happen.
Anyway the way I deal with it is to mark functions I want to debug with a macro that disables optimizations just for that function.
tracy_force_inline void swap( Vector& other )
{
uint8_t tmp[sizeof( Vector<T> )];
memcpy( (char*)tmp, &other, sizeof( Vector<T> ) );
memcpy( (char*)&other, this, sizeof( Vector<T> ) );
memcpy( (char*)this, tmp, sizeof( Vector<T> ) );
}
Will people who write C++ in 202x gamedev do it? Nah, I don't think so. Just stop even maintaining that pesky 'Debug' build and it will be fine. Build configurations grow in other direction. There are optimized configurations already that do not need local build step - LTO/PGO and friends. People just do not build that locally and real world performance is there.
YMMV of course.
Realistic scenario that gamedev uses: deoptimize translation units you are interested in finding or reproducing bugs.