Asp Forum - Better profiling for ruby?

Daniel Martin

7/28/2006 1:44:00 PM

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...). 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?

8 Answers

Jano Svitok

7/28/2006 1:54:00 PM

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

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

J.

On 7/28/06, Daniel Martin <martin@snowplow.org> wrote:
> 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...). 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?
>
>

pat eyler

7/28/2006 2:18:00 PM

On 7/28/06, Jan Svitok <jan.svitok@gmail.com> wrote:
> 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-ru...
> (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.

>
> J.

--
thanks,
-pate
-------------------------
http://on-ruby.bl...

Justin Collins

7/28/2006 5:12:00 PM

Daniel Martin wrote:
> 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...). 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/...

-Justin

cfis

7/30/2006 6:25:00 PM

Daniel,

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

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

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

Thanks,

Charlie

cfis

7/30/2006 6:32:00 PM

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-c...

Hope this helps,

Charlie

Charlie Savage wrote:
> Daniel,
>
> Take a look at ruby-prof, http://ruby-prof.ruby..., which Shugo
> and I put together.
>
> The graph profile output will show you what you want. Here is an example:
>
> http://ruby-prof.ruby...graph.html
>
> Thanks,
>
> Charlie
>
>
>

Daniel Martin

7/31/2006 10:49:00 AM

Charlie Savage <cfis@savagexi.com> writes:

> The graph profile output will show you what you want. Here is an example:
>
> http://ruby-prof.rubyforge.org/...

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

8/1/2006 8:51:00 AM

In message <87u051n8tg.fsf@esau.martinhouse.internal>, Daniel Martin
<martin@snowplow.org> writes
>Now, is there any way to get this kind of information for ruby? I'd

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

Stephen
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/sof...
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

cfis

8/1/2006 10:44:00 PM

Hi Daniel,

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

http://cfis.savagexi.com/page...

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

Daniel Martin wrote:
> Charlie Savage <cfis@savagexi.com> writes:
>
>> The graph profile output will show you what you want. Here is an example:
>>
>> http://ruby-prof.rubyforge.org/...
>
> 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.
>
>

comp.lang.ruby

Better profiling for ruby?

Daniel Martin

Jano Svitok

pat eyler

Justin Collins

cfis

cfis

Daniel Martin

Stephen Kellett

cfis

x Login to ForumsZone