I'm just more inclined to believe that it's not the templating engine per se. Even if you were rendering huge templates, loops with helpers inside or what have you, I really doubt that erubis is to blame.
I can't verify Mikel's claim that the logs would show as if the query happened in the controller, but if that's the case, then I got no idea. > Are you doing anything like render @my_massive_array_of_records ? because > that stuff > can be slow. Not if it's all in memory already. And of course, depends on how complex the partial for rendering a result is, but still... his log paste showed ~4s renders. > Not sure if this still applies to Rails 3, but I have found some startling > performance > improvements if you move the initialisation of @my_massive_array_of_records > out of the > controller and into a helper that is called form the view ... not exactly > MVC-pure :-) Neither is the approach of query-on-use that ActiveRecord 3 takes. But that's what makes Arel's wheels spin. On Wed, Sep 22, 2010 at 1:41 PM, Ivan Vanderbyl <ivanvander...@gmail.com> wrote: > Are you doing anything like render @my_massive_array_of_records ? because > that stuff can be slow. > > On 22/09/2010, at 1:39 PM, Steve Hoeksema wrote: > >> While there are quite a few of them (~40) in the complex example, each >> query is quite fast (<1ms). I haven't done any optimization of the >> queries yet, so it's possible the queries themselves are slow, but not >> the ones that Rails picks up in the logs. >> >> I was hoping to avoid dealing with caching as this is merely an >> internal app, but I guess I'll need to go that way or have a look at >> RPM. >> >> On Wed, Sep 22, 2010 at 3:35 PM, Mikel Lindsaar <raasd...@gmail.com> wrote: >>> On 22/09/2010, at 1:23 PM, Julio Cesar Ody wrote: >>>> Isn't that because ActiveRecord 3 only fires the actual query when you >>>> enumerate a collection? (read: call #each, for example) >>> >>> While this is true, the Rails 3 instruments library wraps those calls >>> pretty well. And IIRC will separate that out correctly in the log. >>> >>> The most effective way to go about fixing this view rendering problem is a >>> good partial caching implementation. >>> >>> Mikel >>> http://lindsaar.net/ >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ruby or Rails Oceania" group. >>> To post to this group, send email to rails-ocea...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> rails-oceania+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/rails-oceania?hl=en. >>> >>> >> >> >> >> -- >> Steve Hoeksema >> +64 224 623 269 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to rails-ocea...@googlegroups.com. >> To unsubscribe from this group, send email to >> rails-oceania+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-ocea...@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- http://awesomebydesign.com -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
