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
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)
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
So, is the concept a flyer? What have I missed?
Ed
--
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.
