On Sep 16, 11:59 pm, Roger Pack <[EMAIL PROTECTED]> wrote: > > By refactoring my code very frequently and keeping an eye on what SQL > > queries AR creates, I can increase my app's performance by x5 on some > > critical processing. My biggest increase was actually x1000 by working > > on tuning the DB with a very big table of 100k rows. > > Interesting, so it's AR loading that was troublesome. > > Well with the release of 2.2 and some non blocking IO drivers [4] > hopefully it will put some more focus on speed, since there will no > longer be an excuse of "well all the latency is caused by IO" I hope :)
Most of the time, the significant overhead is with AR composing the resultset into AR objects. Most benchmarks I saw report small times on the DB side (even with large resultsets). Of course, the smaller the resultset, the less objects AR has to compose so it's always a good idea to watch the SQL. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
