effective profiling

[Giles Bowkett]

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?

 

[Alex Young]

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

 

[M. Edward (Ed) Borasky]

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