On Mar 7, 10:31 am, Brian Adkins <lojicdotcomNOS... / gmail.com> wrote:
> khai... / enigo.com wrote:
> > On Wed, 7 Mar 2007, Brian Adkins wrote:
>
> >> When running a test that primarily involves loading up a few MySQL
> >> tables with ActiveRecord objects, I was surprised to see the Ruby CPU
> >> utilization at 93% and the MySQL CPU utilization at 7%. I would expect
> >> this workload to be heavier on MySQL than that.
>
> >> I would think inserts (particularly with updating several foreign key
> >> indices) would tax the database more than Ruby.
>
> >> Has this been other folks' experience? Is running in the test
> >> environment incredibly different than production with respect to CPU
> >> utilization? I suppose my next step is to run in production to see
> >> what kind of results I get.
>
> > No, that isn't surprising.  Any ORM trades CPU utilization outside of
> > the database for convenience in the data representation.  AR is fairly
> > heavyweight in that regard, so it's doing a lot of work to give you the
> > API that it does.  Latency to a database can be a significant bottleneck
> > to some applications, but relatively speaking, CPU utilization by the db
> > will usually be a small fraction of the CPU utilization of the ORM using
> > application that is talking with the db.
>
> I agree about ORMs trading CPU for convenience, but I've used other ORMs
> (such as Hibernate with Java), and I don't recall the CPU ratio to be
> quite so high. In fact, my prior experience has always been that a piece
> of code such as I'm using would be database bound, and not CPU bound. I
> mean, seriously, all the code is doing is a bunch of database inserts!
>
> Also, since I'm not using stored procedures with Rails, MySQL has to
> work harder to parse the statements, so if stored procedures were used,
> the Rails/MySQL CPU ratio would be even higher than 93/7.
>
> Frankly, it's not worth my time to whip up a Java/Hibernate example for
> comparison, but I'm pretty darn curious now - both at what the CPU ratio
> would be as well as the time for completion.
>
> I'm willing to live with it, but that doesn't mean I have to like it :)
>
>
>
> > Kirk Haines

I'd definitely echo the perception that AR is unreasonably taxing on
the CPU.
Because it is. Performance just hasn't been a focus for it. Load up
1,000 AR
records with 10 attributes and you've got 10,000 strings to represent
the
column names. That's just one example. I'd expect Og to be faster, but
that's just a guess since I haven't actually benchmarked it.

I wasn't trying to imply looking at other languages, just maybe other
techniques. As I understand it Og+Rails has some issues right now
because
ActiveSupport and Facets step on each other (that's just what I gather
from
the nitro-general list). But I imagine contributing to resolve the
issues
between Og & Rails probably isn't as great an undertaking as making AR
faster.
Depending on Og's performance that may or may not be worthwhile I
suppose.

One other thing to consider though: MySQL is the fastest mainstream
database
I know of by a large margin, especially concerning INSERT and UPDATE
performance. So if you were using Oracle or MSSQL before, that would
skew
the results a bit more.