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?
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 (Running With Scissors). 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?
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 (Running With Scissors). 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.
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
--
Stephen Kellett
Object Media Limited http://www.objmedia.demon.co.uk/software.html
Computer Consultancy, Software Development
Windows C++, Java, Assembler, Performance Analysis, Troubleshooting
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.)
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.
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:
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.