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