Steven,
That's pretty cool. I hadn't seen that before, but that seems like a
fantastic approach if you were in the position of using a LOT of selectors.
My solution wouldn't scale to that extent. I find, in most cases, that I
never have to resort to using selectors more than a handful of times, so
I think this has come up on Roro before (by someone at Envato?) but I
can't find it through search.
I'm finding that views are becoming by far the slowest part of my app,
eg for a reasonably complex page:
Completed 200 OK in 841ms (Views: 657.3ms | ActiveRecord: 27.5ms)
Or for a more complex one
Isn't that because ActiveRecord 3 only fires the actual query when you
enumerate a collection? (read: call #each, for example)
Your problem might still be data-bound.
On Wednesday, September 22, 2010, Steve H wrote:
> I think this has come up on Roro before (by someone at Envato?) but I
> can't
I find RPM Lite (free) from http://www.newrelic.com to be very handy to get
a quick breakdown of where you transaction is spending its time.
Cheers,
Anthony
On Wed, Sep 22, 2010 at 12:47 PM, Steve H wrote:
> I think this has come up on Roro before (by someone at Envato?) but I
> can't find it
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
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 t
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
> queri
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 :-)
On Wed, Sep 22, 2010 at 1:41 PM, Ivan
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 control
On 22/09/2010, at 1:35 PM, Mikel Lindsaar wrote:
The most effective way to go about fixing this view rendering
problem is a good partial caching implementation.
On the other hand, any view that takes four seconds just to render
deserves a closer look... even if you wind up caching it anyhow.
It has looped and nested views, plenty of form helpers and link_to.
Looking in RPM no one particular method seems to be slow, it's just a
large number of small ones.
Given it's an internal project for use by a handful of people
irregularly I'll just leave it be.
On Wed, Sep 22, 2010 at 4:01 PM,
Hi everyone,
The Canberra Ruby Crew will be meeting for September next Wednesday night.
This time around it will be a hack night. Bring something to work on.
WHEN: Wed 29th September, from 6:30pm.
WHERE: Icelab, Unit 3, The Metropolitan, 1 Gordon St, Civic
(http://icelab.com.au/)
WHAT: Hacks & e
On 22/09/2010, at 2:13 PM, Steve Hoeksema wrote:
> It has looped and nested views, plenty of form helpers and link_to.
>
> Looking in RPM no one particular method seems to be slow, it's just a
> large number of small ones.
>
> Given it's an internal project for use by a handful of people
> irregu
Hi everyone,
Just a brief message that if you've built something cool in the last 12 months,
and want some
recognition or want to bring recognition to your team or organisation for a web
project, then read
on!
Our very own Michael Koukoullis (@kouky) won this prize in 2007.
J
=
Tutoring Australasia is looking for a Uni student to join our development
team for a three month Summer internship as a junior developer.
Ideally, you are:
- Comfortable with Rails apps and know enough HTML, CSS, Ruby, and
Javascript to build your own apps.
- Interested in leveling up your Rails s
So as a quick aside, if one was instead to see this:
Completed in 4208ms (View: 115, DB: 159)
Is that indicative that the controllers are where all the time is being
spent?
And what if in another scenario:
30 units => Completed in 6183ms (View: 28, DB: 793)
10 units => Completed in 190
16 matches
Mail list logo
