Rails - Nov 2005 - Two Controllers vs One Big Controller with many actions

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 Kaes" <skaes-hi6Y0CQ0nG0@public.gmane.org> wrote in
message
news:437DF186.9030003-hXc8xaejXB+tXF2fZOsJYA@public.gmane.org
> 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 ;-)

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.

On 11/18/05, Vurg <virgild-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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 Kaes" <skaes-hi6Y0CQ0nG0@public.gmane.org> wrote in
message
> news:437DF186.9030003-hXc8xaejXB+tXF2fZOsJYA@public.gmane.org
> > 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 ;-)
>
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>