Effective profiling

I have a friend who’s run into some profiling problems. He set up a
profiler on a Rails app, maybe the default benchmarking stuff Rails
comes with, I’m not sure. Unit tests run 60s normally, and come in at
an hour and a half with the profiler going.

That sounds pretty extreme to me. What’s the best way to profile a big
app in Ruby? They’ve got a lot of recursive cloning going on, I think
that’s probably the issue, but how do they find out for sure?

Giles B. wrote:

I have a friend who’s run into some profiling problems. He set up a
profiler on a Rails app, maybe the default benchmarking stuff Rails
comes with, I’m not sure. Unit tests run 60s normally, and come in at
an hour and a half with the profiler going.
Is that with profile (rather slow) or ruby-prof (should be much faster)?

Giles B. wrote:

I have a friend who’s run into some profiling problems. He set up a
profiler on a Rails app, maybe the default benchmarking stuff Rails
comes with, I’m not sure. Unit tests run 60s normally, and come in at
an hour and a half with the profiler going.

That sounds pretty extreme to me. What’s the best way to profile a big
app in Ruby? They’ve got a lot of recursive cloning going on, I think
that’s probably the issue, but how do they find out for sure?

Perhaps premature optimization isn’t so bad after all. :slight_smile: Seriously,
though, profiling is a form of testing, and if you’re going to do
test-driven development but not performance testing, you’re finding
only some of the bugs. So the best way to profile a big application,
assuming a total absence of software performance engineering during its
construction, would be to break it up into smaller pieces in top-down
fashion.


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.net/

If God had meant for carrots to be eaten cooked, He would have given
rabbits fire.