I have two controllers with about 12 actions each, and since the two are
very closely related, I’m trying to merge them into just one controller.
What is the effect of this in terms of performance? I’m really not
trying to
do some deep optimization here, just want to find out if it will matter
in
case performance becomes an issue later.
Vurg wrote:
I have two controllers with about 12 actions each, and since the two are
very closely related, I’m trying to merge them into just one controller.
What is the effect of this in terms of performance? I’m really not trying to
do some deep optimization here, just want to find out if it will matter in
case performance becomes an issue later.
There will probably be no noticable speed difference, unless both have
differing filter needs. Potentially you could end up with twice as many
filters, or complicated :exclude, :include filter conditions. This could
slow your app down a bit.
– stefan kaes
PS: http://railsexpress.de/blog talks about Rails performance issues.
Subscribe 
I’ll take note of that.
Another thing that comes to my mind is a bigger controller class will be
slower to instantiate than one with less methods. But I’m not sure about
this yet.
“Stefan K.” [email protected] wrote in message
news:[email protected]…
Methods don’t matter in regards to instantiation as most OO
languages–e.g. Java–implement instances in a ‘flyweight’ fashion.
To be clearer, non-static (or in ruby, non-class) methods are really
just static methods (from an implementation perspective) with an
associated context (instance variable values).
That being said, I’m not sure Ruby does this–although I would be
surprised to hear otherwise.
I don’t think merging things for performance reasons makes sense (even
if it did lead to slightly better performance, which it probably
wont). I’d recommend keeping semantics as the primary driver for
collocating stuff, as hardware is so much cheaper than manpower these
days.