On Miércoles, 2 de Diciembre de 2009 20:29:17 Ed W escribió:
> Right now AS is slowed down significantly by a) the garbage collector
> cleaning up a lot of small temp variables we create all over the place
> and b) the fairly in depth code which is used to decide how to render
> every column (which is called repeatedly for every row and every cell)
>
> Could Sergio or someone similar please comment on whether a patch would
> be accepted to change the rendering algorithm to be a two pass algorithm
> where we effectively "compile" a bunch of functions to render each
> colum, eg something like:
>
> (in list_column_helpers)
> def render_list_column
> self.send("column_#{column}")
> rescue
> define_render_list_column #create a column override function
> self.send("column_#{column}")
> end
> end
I don't know if it's a good idea. It could break per-request configuration,
changing form_ui in create and update actions for example, maybe it's not used
too much but I think it's possible to improve performance without breaking it.
Is it possible to remove a method? It could be a fix for per-request
configuration changing form_ui.
Also, what do you think about caching what method call in an attribute of
column? We should homogenize arguments for overrides and form_ui methods for
using that.
>
> Where the define function effectively just creates a normal column
> override. This way we have symmetry between whether the developer
> overrides a column, or whether we create one dynamically on first run
>
> Question is whether this spoils anything for anyone? Also ideally I
> would like to do all that complex "options" mangling just once at the
> beginning for each column? (I don't see any room in AS at present for
> "per-row" options, so I don't believe this breaks anything for anyone?
> You can always override the column formating function if you needed to)
>
> Second question is where we should define the override function (ideally
> we want it above the users controller so that if they declare an
> override programmatically it overrides our override...)
>
> I believe this kind of change will lead to a fairly substantial speedup
> of AS because I see 10%+ speedups just caching a couple of calls to
> "respond_to?" (It's quite a slow call). I think also it will make the
> logic easier to follow and extend, especially in the show/create views,
> because there is a much clearer separation between deciding how to
> render a column and the code which does the rendering (at the moment you
> need to follow a lot of IF's and the rendering itself is then done right
> down at the bottom of that big IF tree)
Caching the method for render we can put the logic in other method, and method
which render only should to fill the caching attribute if it's empty
(caching_attribute ||= method_with_caching_logic) and then use that method.
>
> Also, as a general coding style please try to avoid doing things like
> taking an options hash, filtering it and returning a new options hash,
> in the inner loops. It leads to lots of temporary objects being created
> and I observe that this often leads to the GC firing repeatedly *during*
> the rendering step (rather than just at the end) leading to quite a
> substantial slowdown. This is going to be a bit more tricky to code
> around because it's used quite extensively in the current AS code, but
> please try to avoid it as a general trend going forward
I think this is easier to improve, it should be our fist step IMHO, although
more tests would be useful to avoid regressions with these changes.
--
Sergio Cambra .:: entreCables S.L. ::.
Mariana Pineda 23, 50.018 Zaragoza
T) 902 021 404 F) 976 52 98 07 E) [email protected]
--
You received this message because you are subscribed to the Google Groups
"ActiveScaffold : Ruby on Rails plugin" 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/activescaffold?hl=en.
