Elaborate on which bit?
Prepared statements - It was always considered a truism that 85% of
the time spent in a Rails App is in the database. Since Rails
generates its SQL on the fly and submits it new every time, it has to
repeat the work of the “prepare” every time. When I questioned this,
I was told that “not all RDBMS’s support prepared satements”.
The RDBMS one of any note that fits that description is MySQL. Even
MS-Access has the concept, even if it is implemented oddly.
In direct measures, 50 to 85% of the time that dynamic SQL is
processed centers on the prepare phase. Use of a prepared statement
has this overhead once, then only the time in wire communications and
actual execution thereafter. An obvious and painless performance
enhancement would be to use prepared statements over SQL strings for
the bulk of Rails’ transactions.
A couple of people on this list have done so and publised timing
results, showing that Rails benefits spectacularly from the use of
An additional but less important boost comes because, when using a
prepared statement, only the handle (an integer ususally) to the
statement and the parameters cross the wire on execution. Finally,
prepared statements offer a level of security and eliminate the need
for the overhead of the “sanitize” method that tries to prevent string
substitution attacks on every SQL invocation.
With all of these benefits, the resistance to adopting prepared
statements was very surprising to say the least. For the most part,
the arguments against it were “MySQL doesn’t do prepared statements
yet, so Rails won’t”
Small-systemsisms - for starters, see above. On large systems,
efficiency is important because you pay by the CPU cycle. Anything
that is a performance drag is also spending real dollars. A rails
front end, because it replicates the expensive work of the SQL prepare
on every call, is expensive to operate against a large-systems back
Scalable transactional systems - see above. I could dig out more
examples, but this one example shines.
Does this help?