Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Sad State of Debug Performance in C++

vittorioromeo.info

Post reply on HN
Print view View original

41–50 of 111 posts

Re: The Sad State of Debug Performance in C++

#41

Post by mort96 »

bluedino wrote: post #26
Decabytes wrote: post #16

Earlier quoted context omitted.

Not exactly what you were asking, but RAD tried to build a debugger for Linux^1, but the project died. I’ve heard the people at RAD described as hard core old school programmers, so if they struggled with this it must just be a hard problem 1. http://www.radgametools.com/debug.htm

>> To put it bluntly, debugging on Linux is just really bad. We believe it is the biggest roadblock to great software for that platform. That article is ~10 years old, is that still true?

GDB is still the king of debugging on Linux. GDB is still a really bad debugging experience. GDB front-ends are still incredibly buggy and best avoided unless you wanna debug why your debugger just broke.

Re: The Sad State of Debug Performance in C++

#42

Post by staticassertion »

With our rust project we actually compile with `01` because the cost of that optimization pass is less than the cost to our tests running 100x slower. There is definitely a need for a 'more optimal' debug mode, and it is one of those things that feels zero cost until it isn't. Similarly, I try to at least consider compile times when writing code these days.

Re: The Sad State of Debug Performance in C++

#43

Post by leni536 »

_gabe_ wrote: post #35

I ran into these problems with std::unordered_map. While developing my game, I would always run it in debug mode because I need to debug it. Loading a game world was taking around 12 seconds, and it was beginning to grate on me because of the increased iteration times. So I decided to profile it and see what was taking so long. I compiled in release mode to begin debugging, and it magically took the world load time d…

> debug iterators

MSVC then, I presume.

Re: The Sad State of Debug Performance in C++

#44

Post by gernb »

_gabe_ wrote: post #35

I ran into these problems with std::unordered_map. While developing my game, I would always run it in debug mode because I need to debug it. Loading a game world was taking around 12 seconds, and it was beginning to grate on me because of the increased iteration times. So I decided to profile it and see what was taking so long. I compiled in release mode to begin debugging, and it magically took the world load time d…

It'd maybe be nice to be able to mark which code gets optimized. If I could make all std as "don't debug this and keep it optimized" I would. I know some debuggers have the option to at least not step into certain code that that doesn't solve the optimization issue

Re: The Sad State of Debug Performance in C++

#45

Post by jotux »

cyber_kinetist wrote: post #15
BenFrantzDale wrote: post #4

It’s always nice to understand more about why game developers do the weird things they do. I always buried and run in “RelWithDebInfo”, then if I really need it, I’ll throw `#pragma clang optimize off` around the code that the debugger can’t see into.

Really nice tip to know! I've also struggled a lot with slow debug performance, so this will be very handy when I know there's a bug somewhere in a specific region but can't pinpoint exactly where.

GCC has something similar:

>#pragma GCC optimize ("O3")

https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Function-Specif...

Re: The Sad State of Debug Performance in C++

#46

Post by PaulDavisThe1st »

I've been using C++ since 1993. I still don't understand how I've written all this code and never once found myself using, or wishing I could use std::move.

Presumably my code has been less than optimally efficient or something, because it seems that most people talking about "modern" C++ view it as absolutely central to the language.

Re: The Sad State of Debug Performance in C++

#47

Post by chubot »

It's also annoying for tools -- like debuggers, and uftrace (user space function tracing), which will start showing all these tiny functions that you don't really care about

I prefer to avoid all the operator overloading and smart pointers, etc.

Re: The Sad State of Debug Performance in C++

#48

Post by usefulcat »

adrian_b wrote: post #12
usefulcat wrote: post #8

Earlier quoted context omitted.

It's not just inlining. With -Og (clang or gcc), the debugger frequently can't even tell me the value of function arguments because they've been "optimized out".

While I agree with you and with the OP and I have also been sometimes annoyed by this kind of debugger messages, the more universal solution than wanting an improved debugger is to rely for debugging on some form of progress and error logging in your program, which will work at any optimization level. Adding such debugging aids in your program may need some extra work, but it also functions in all cases when using th…

Yes and no. I use logging too, but that's only useful when I know (or can guess) ahead of time what locations and what things at each location I'll need to know in order to diagnose the problem.

Of course I can always go back and add some logging, but it's not a given that I'll want to keep it around after the problem is fixed. For example if it's in a performance-critical section of code, even the cost of checking to see whether logging is enabled may be too great. And in any case every log statement does add visual noise to the code.

Re: The Sad State of Debug Performance in C++

#49

Post by TillE »

gernb wrote: post #44
_gabe_ wrote: post #35

I ran into these problems with std::unordered_map. While developing my game, I would always run it in debug mode because I need to debug it. Loading a game world was taking around 12 seconds, and it was beginning to grate on me because of the increased iteration times. So I decided to profile it and see what was taking so long. I compiled in release mode to begin debugging, and it magically took the world load time d…

It'd maybe be nice to be able to mark which code gets optimized. If I could make all std as "don't debug this and keep it optimized" I would. I know some debuggers have the option to at least not step into certain code that that doesn't solve the optimization issue

As others have mentioned, you can accomplish the equivalent by using a release build with pragmas to turn off optimizations in certain sections of code.

Re: The Sad State of Debug Performance in C++

#50

Post by the-lazy-guy »

PaulDavisThe1st wrote: post #46

I've been using C++ since 1993. I still don't understand how I've written all this code and never once found myself using, or wishing I could use std::move. Presumably my code has been less than optimally efficient or something, because it seems that most people talking about "modern" C++ view it as absolutely central to the language.

std::move is not only about performance. It is about being able to disallow destructive copies of certain types. I.e. unique_ptr can not be copied, and auto_ptr can. Can you write perfectly functioning code without these features? Sure! You just have to be accurate.

Same with performance. Where nowadays simple std::move() on a return value suffices you had previously explicitly to pass the object/vector with which you swapped as a parameter.

Life with move semantics is a tad easier.

Post reply on HN