<troll-feeding-troll>
Short linear search from high probability starting point is faster due to locality. And that's why GDB is better most of the time, but sometimes becomes inefficient.
</troll-feeding-troll>

-
-
-
1. needs a huge short-term memory to keep entire program flow in “cache”/brain
2. Cache miss-prediction is a thing in my GDB usage: Step, Step, ..., Doh missed it. - 3 more replies
New conversation -
-
-
I definitely had a lot of insecurity about being a print-based debugger since that was discouraged in uni, but it worked for me so I kept leaning on it. Then I found out Google mostly does print debugging and their internal gdb is barely maintained. :D
-
Guilty as charged :)
- 2 more replies
New conversation -
-
-
The only reason I prefer printf over a debugger is because, historically, I've had a debugger available approximately never. :|
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
A human is much better at scanning visuals than text. That's why you use tracing instead of printfs or gdb. Rebuilding is slow, thats why you use uprobes instead of printfs. __builtin_printf to printf to skip stdio.h </trolling> I prefer rr to gdb and wish I had pernosco.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Ugh I just read this and now I want a feature in the Emacs debugger that I’m building where you can search through all the state you’re tracking and find the first instance where it became some value
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.