Hacker News Reader

This reminds me of a clever hack I learned for finding bottlenecks when using a debugger or in cases where you're able to get a backtrace from a running program.

If you run the program and then just randomly trigger the debugger with CTRL-C.. the probability is that you're likely to have landed on a slow code path because that's where the program is spending most of its time.

View on HN

...which is exactly how stack-sampling profilers work. They just automate doing this thing (and recording the stack trace) every x milliseconds.

Or, if you have a semi-locked down production box and a process that's already gone unusably slow, a quick shell loop that calls pstack on the slow process 10 times will get you a good idea where the process is spending its wall clock time. (I've seen locked-down environments where pstack can be run, but gdb can't.)

Note that pstack will probably take a bit for each stack snapshot it prints. It has to attach as a debugger, walk the stacks, and read the symbol tables each time. It's easy for the whole process to freeze for a second or two, so you probably don't want to do this on a production process that is limping along okay-ish.

Reply on news.ycombinator.com