Better profiling for ruby?

[Daniel Martin]

So the recent performance threads have all repeated the wisdom
"profile first" in various forms, and various ways.

I have a problem with this. I can't read the output of the ruby
profiler and get meaningful insights on my script.

Invariably, the profiler will tell me that almost all of my time is
being sucked up in Range#each or Integer#upto. In other words, the
profiler is telling me that my time is being sucked up into some loop
somewhere. Thanks a bunch; any idea which of the twenty loops in my
program that is?

Over in the perl world, my favorite profiler has been
Devel::SmallProf. I've found there's nothing to compare with it for
producing those surprising "so *thats* where all my time has been
going" moments. It does this by giving me an easy feedback on which
lines of my program suck up the most time (both in terms of that line
directly and, if the line contains a sub call, the lines it calls).
I've found this line-number-based approach to profiling incredibly
helpful, much more helpful than traditional method-based summaries.

In fact, I found this approach so useful that I even implemented it
for java (http://perlmonks.org/?node_id=381641). This has been a real
blessing in my current job, allowing me to focus performance tuning at
a level that seems natural.

Now, is there any way to get this kind of information for ruby? I'd
like to be able to look at the output of a profiler and get some
information useful to making the script faster out of it. Barring
that, is there somewhere on the web a worked example of taking a
initial (nontrivial) ruby script, working with the profiler, and
ending up with a faster script?

 

[Jan Svitok]

I don't know whether this article fits into 'trivial' category or not:

http://www-128.ibm.com/developerworks/edu/os-dw-os-ruby2-i.html
(registration needed)

J.

 

[pat eyler]

I don't know whether this article fits into 'trivial' category or not:

It almost certainly does. I wrote it as an introduction profiling and
benchmarking for beginning Ruby programmers. I (or someone)
should probably write a more advanced example. (It would be
awesome to look over Zed's shoulder while he works on mongrel --
hint, hint.)

http://www-128.ibm.com/developerworks/edu/os-dw-os-ruby2-i.html
(registration needed)

Thanks for the link though.

On an unrelated, but important, note -- try not to top post. It
makes your reader work harder to get the context for your
comments and/or questions.

 

[Justin Collins]

So the recent performance threads have all repeated the wisdom
"profile first" in various forms, and various ways.

I have a problem with this. I can't read the output of the ruby
profiler and get meaningful insights on my script.

Invariably, the profiler will tell me that almost all of my time is
being sucked up in Range#each or Integer#upto. In other words, the
profiler is telling me that my time is being sucked up into some loop
somewhere. Thanks a bunch; any idea which of the twenty loops in my
program that is?

Over in the perl world, my favorite profiler has been
Devel::SmallProf. I've found there's nothing to compare with it for
producing those surprising "so *thats* where all my time has been
going" moments. It does this by giving me an easy feedback on which
lines of my program suck up the most time (both in terms of that line
directly and, if the line contains a sub call, the lines it calls).
I've found this line-number-based approach to profiling incredibly
helpful, much more helpful than traditional method-based summaries.

In fact, I found this approach so useful that I even implemented it
for java (http://perlmonks.org/?node_id=381641). This has been a real
blessing in my current job, allowing me to focus performance tuning at
a level that seems natural.

Now, is there any way to get this kind of information for ruby? I'd
like to be able to look at the output of a profiler and get some
information useful to making the script faster out of it. Barring
that, is there somewhere on the web a worked example of taking a
initial (nontrivial) ruby script, working with the profiler, and
ending up with a faster script

ruby-prof is pretty neat. I haven't used it a lot, but I feel it's a bit
more informative (and much faster) than the standard Ruby profiler.

http://rubyforge.org/projects/ruby-prof/

-Justin

 

[Charlie Savage]

Daniel,

Take a look at ruby-prof, http://ruby-prof.rubyforge.org/, which Shugo
and I put together.

The graph profile output will show you what you want. Here is an example:

http://ruby-prof.rubyforge.org/graph.html

Thanks,

Charlie

 

[Charlie Savage]

One thing I forgot - I wrote up a bit more information about ruby-prof
on my blog at:

http://cfis.savagexi.com/articles/2006/06/21/ruby-prof-0-4-0-with-call-graphs

Hope this helps,

Charlie

 

[Daniel Martin]

The graph profile output will show you what you want. Here is an example:

http://ruby-prof.rubyforge.org/graph.html

While I have no doubt that it shows me something, I had no idea what
that might be until I tracked down prime.rb in the source - if this is
supposed to be readable without access to the code being tested, I
don't understand. (And if it isn't supposed to be readable without
looking at the test source, why is it so hard to find that source
file? I shouldn't have to download the distribution to be able to
read the documentation.)

Now that I've seen the source, and gone over what it says in
graph.txt, I have a slightly better idea. This might indeed be able
to tell me something; I'll have to try it thw next time I'm trying to
optimize ruby.

It'd still be nice to have something like perl's Devel::SmallProf, but
I think I can live without that for a bit.

 

[Stephen Kellett]

Now, is there any way to get this kind of information for ruby? I'd

Ruby Performance Validator
http://www.softwareverify.com/ruby/profiler/index.html

Stephen

 

[Charlie Savage]

Hi Daniel,

Good point on making prime.rb available on line - here it is:

http://cfis.savagexi.com/pages/prime.rb

I also updated my blog entry.

Anyway, graph profiles definitely take some getting used to. But they
answer the question you had - given a particular hotspot in the code how
does that code get executed (what methods call it, what methods does it
call).

I wrote up some documentation via Rdoc, but another great source of
information is doing a search for GProf tutorials.

As far as SmallProf, I've never used it. What do you like about it?

Thanks,

Charlie