I'm investigating different optimization techniques, and I came across this post Analyzing Code for Efficiency? by someone who believes that sampling the call stack is more effective than using a profiler. The basic idea is that if you take a view of the call stack, you see where your application is most likely to be spending most of its time, and then optimize there.

It is certainly interesting, and he is obviously an expert on this, but I don't know how to view the call stack in ruby. In debugger I can say "info stack" but only seems to show one line.

EDIT: I saw this comment by Mike Dunlavey: "I would just like to point out that if you run under the debugger, interrupt it manually, and display the call stack..."

I'm just not sure how to interrupt it manually and dipslay the call stack.

This doesn't seem to answer the question. Printing the call stack at a specific point in your code can be useful, but it is not a random sample. It won't tell you what's on the stack at a randomly-chosen points in time.
–
antinomeMay 6 '14 at 19:23

Does this work in the context of performance optimization? If the idea is to see a stack trace at a point when the application is running slowly, it seems like you have the catch-22 situation of knowing where the bottleneck is, in order to add this code at the correct spot?
–
d11wtqJun 13 '11 at 0:39

@d11wtq, The idea is to run your app between begin and rescue, and hit Ctrl-C when the app is slow. That will tend to land on the thing that the app spends most of its time doing. Optimizing that will give the most bang for the buck.
–
MoriJun 13 '11 at 3:17

Ah, ok thanks. When I do that in 1.9.2. I just get Interrupt and a stack trace regardless of the begin..rescue block. Where does the begin..rescue block come into play when the process is terminated with a SIGINT? I fear I may be being a bit blonde here o_O
–
d11wtqJun 13 '11 at 7:08