Live data from Hacker News

The Sad State of Debug Performance in C++

vittorioromeo.info

51–60 of 111 posts

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

#51
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…

Isn't it just a matter of /D_ITERATOR_DEBUG_LEVEL=0?

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

#52
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…

How do you see the key/value pairs with robinhood in debug mode? I could never find them.

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

#53
post #19

I'm with Kernigham and Pike: the debugger is for getting a stack trace out of core dumps. Printf is for debugging.

Why limit yourself to crusty text when you can have live visualizations of data structures in various formats, graph dx/dy over time of some variable, stop and inspect data on some condition without having to modify code, quickly start execution on a certain line, quickly drill down into struct members, etc.

I mean it does everything a printf() can do - except just better.

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

#54
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…

Second recommendation for robin_hood's map. I've used it as well, excellent performance compared to the default implementation in GCC.

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

#55

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.

> Presumably my code has been less than optimally efficient or something

Yep, it was either less efficient than it could be, or more clunky, or incorrect.

I remember back when boost was still a thing, everyone using boost::shared_ptr indiscriminately. Refcounting has a very nontrivial cost to it if implemented correctly.

Things like rvalue refs and std::move allow to properly implement the concept of "ownership transfer", obviating the need for costly ref counting in the majority of cases.

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

#56
post #19

I'm with Kernigham and Pike: the debugger is for getting a stack trace out of core dumps. Printf is for debugging.

Why limit yourself to crusty text when you can have live visualizations of data structures in various formats, graph dx/dy over time of some variable, stop and inspect data on some condition without having to modify code, quickly start execution on a certain line, quickly drill down into struct members, etc. I mean it does everything a printf() can do - except just better.

For a couple months I had no functioning debugger and was left with only Printf's. I do not ever desire to go back to that. It is far too painful. I think my time to find issues likely was 4x+ longer than before.

Some programs simply have too much state, too complex of structures (for performance or memory reasons), or very long runtimes to reasonably debug purely with prints.

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

#57

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.

You can absolutely write the same programs without std::move(), using out parameters for objects of expensive construction. Move semantics were introduced because they're a clear ergonomic win.

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

#58
post #19

I'm with Kernigham and Pike: the debugger is for getting a stack trace out of core dumps. Printf is for debugging.

Why limit yourself to crusty text when you can have live visualizations of data structures in various formats, graph dx/dy over time of some variable, stop and inspect data on some condition without having to modify code, quickly start execution on a certain line, quickly drill down into struct members, etc. I mean it does everything a printf() can do - except just better.

> Why limit yourself to crusty text when you can have live visualizations of data structures in various formats,

Because that's too fruity, real men (tm) don't use debuggers /s

Programmers are so funny, they'll present themselves as rational and logical, but then follow the advice of some old geezer who thinks syntax highlighting is for pussies rather than admitting that their tools suck and need to be better.

I have a particular chip on my shoulder about this whole printf debugging thing: https://twitter.com/nice_byte/status/1465200027672866816

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

#59
post #19

I'm with Kernigham and Pike: the debugger is for getting a stack trace out of core dumps. Printf is for debugging.

Why limit yourself to crusty text when you can have live visualizations of data structures in various formats, graph dx/dy over time of some variable, stop and inspect data on some condition without having to modify code, quickly start execution on a certain line, quickly drill down into struct members, etc. I mean it does everything a printf() can do - except just better.

I’ve personally never been in a bare-metal environment where the debugger is truly reliable. JVM works great, so does V8 and probably most other VM-style environments, but C++? Swift? Rust? I’ve never seen a truly reliable debugging environment that doesn’t just arbitrarily stop working when I try to inspect a symbol, some subset of the time.

If debuggers were reliable, I’d take them over printf-debugging any day. But to this day I’ve never seen one that is.

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

#60
The author needs to learn about the -Og switch, which can be used together with debugging. It can be thought of as "do those optimizations that don't interfere with debugging". I verified with Godbolt that this suffices to eliminate the call overhead.
Post reply on HN