On Jul 27, 5:38 am, Hal Fulton <hal9... / hypermetrics.com> wrote:
> David Rush wrote:
> > This is just an observation from a relative Ruby (in
> > general) and Rails (in particular) newb.
>
> Direct access to the database probably isn't terribly railsy,
> of course... but a factor of 700 slowdown is obviously
> unacceptable.
>
> And the fact that is such a large factor makes me think that
> *something* must be wrong. I am sure this is not the typical
> person's experience...

Yes. The more I think about it, the more astonished I am. Especially
when my benchmarks which did straight row reads from the DB ended up
running within 20% of each other. I think the main source is a lot of
the 'convenience' features of the rails environment. As an example, I
know that I put in a lot of effort to stop Rails from introspecting
the columns of my habtm's - this is a *huge* time-waster, even if it
is handy when you're rapidly prototyping. Perhaps I should have moved
over to a 'production' environment?

I'm sure that the single biggest thing was being able to directly
implement a cache policy that suited the application, rather than
manipulating it at the long end of a long pole. That fact is probably
also indicative of a number of other small multiplicative factor
errors (many of which are my fault I'm sure) which when compounded
cause the explosion in processing time. Nearly 3 *decimal* orders of
magnitude is just a *huge* margin - if I didn't *know* that I used the
*same* algorithms, I'd be assuming that they must have been changed.

And that's why I just threw it out as a data point. I'm a fairly
experienced professional. What I found frustrating was the difficulty
I had in discovering my performance issues - which I am sure I can't
all lay at the feet of RoR. In my private musings after I posted last
night, I recalled the 'agile development' value expressed in the
introduction of _Agile Web Development with Rails_ that prefers
working code to extensive documentation. Well I know of a few managers
in my day that could have learned to moderate their stance a bit based
on that advice, but the flip side is that documentation is crucial to
re-usability. But that's a rabbit-hole I don't particularly want to
explore today.

david rush
--
http://cyber-rush.org/drr -- a very messy construction^Wweb site