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 Bowkett
http://www.gilesgoatboy.org


Giles Bowkett 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)?

···

--
Alex

Giles Bowkett 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.