 |
 |
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 >