Nate++

This is helpful.  I would suspect 90%+ of my Rails inefficiencies
revolve around being lazy with AR.

-Ross.

On Tue, Apr 8, 2008 at 2:39 PM, Nate Vack <[log in to unmask]> wrote:
> On Tue, Apr 8, 2008 at 9:46 AM, Jonathan Rochkind <[log in to unmask]> wrote:
>
>  >  I'm not really sure how to start.  The fact that I really need to
>  >  include examination of things that happen during view rendering (helper
>  >  methods, but possibly also db access that might unwise be in the view
>  >  code itself) makes me especially confused. Most of the stuff I find on
>  >  the web on this topic is about determining which actions take up most of
>  >  your apps time, or determining how many concurrent users your app can
>  >  handle. Neither of those is what I need to do! I need to get into the
>  >  guts of an already identified action, and figure out how to speed it up.
>
>  First thing, I'd look at the Rails log. It'll tell you how much time
>  you're spending in database and rendering, at least -- though it won't
>  report on 'business logic time', which can be quite large, especially
>  if you're getting lots of ActiveRecord objects (hint: don't do that).
>
>  If that suggests that your queries are slow, the Rails Query Analyzer
>  plugin will show you *a lot* of what's happening, query-wise. It needs
>  MySQL -- but the standard development log will at least tell you every
>  query run (and how long those queries take...?)... so you can use your
>  own database's query analyzer and see what they're up to.
>
>  A few very loose performance rules of thumb:
>
>  * Making AR objects is expensive. Cutting down the number of objects
>  in a collection with more selective SQL is almost always better than
>  filtering with ruby.
>
>  * And if your queries are slow... index, index, index. Try rewriting
>  with subqueries. Or without subqueries. The MySQL query optimizer can
>  be a fickle beast.
>
>  * Make development as close to production as is reasonable. Don't
>  assume that things that are fast (or slow) in sqlite are fast in
>  mysql, or in postgres.
>
>  * Put off getting collections as long as you can (for example, don't
>  do @articles = @person.articles in your controller; just use
>  @person.articles in your view). This will make fragment caching way,
>  way easier.
>
>  * If you need to iterate over a lot of AR objects, it can be a lot
>  better to do it in small batches -- AR doesn't support cursors and
>  will (un)happily load 1,000,000 objects into memory.
>
>  Cheers,
>  -Nate
>