Question about ERB performance

I’m trying out rails 3 and I’m looking at the performance statistics
given by WEBrick.

It says many of my database operations are taking 2ms or 7ms… but
the view is taking 40ms. People often say that the database is the
bottleneck in applications (which it most certainly can be, and often
is)… but isn’t the rendering of ERB a little show here? My test
pages really aren’t that complicated… 1 partial… 1 layout… etc.
The project only has 5 model classes. I am only iterating through a
list of a model once. There are a few link_to() calls, but that’s it.
It’s really very simple.

Does this have something to do with being trying rails on Windows
maybe?

Could it be RubyMine? (I guess I should run WEBrick outside of
Rubymine to see if it affects anything later).

WEBbrick seems to add another 10ms overhead on top of all of this in
most of my pages as well. It does seem weird for thinks to be taking
60-70ms per page. That does seem a little slow for pages so simple.

Comments?

Oh, I see. Is there any way I can find out how long it’s taking to
make the objects? Make an isolated script that does the same thing and
not call into erb at all? Has anyone done these kinds of break downs?

On Apr 13, 5:30am, Frederick C. [email protected]

On Apr 13, 7:22am, egervari [email protected] wrote:

It’s really very simple.

Comments?

First off, make sure you’re in production mode (or at least turn cache
classes on) if you want useful numbers. The other thing is that if you
make database queries in your view, the time it takes to execute those
counts towards view rendering time. This can happen without you
realizing, if you controller did something like

@users = User.active

where active is a scope and then in your view you iterate over @users
then the query to load active users will only execute at the point
when you start to iterate over that array. The other thing is that
activerecord time only seems to count the time to execute the query,
not including the time it takes to massage the results into active
record objects

Fred

For that level of detail, profiling is probably the way to go. Google
“rails
profiling” for your options.

Jeffrey

Quoting egervari [email protected]: