# Effects of a humongous Controller on performance?

**URL:** <https://www.ruby-forum.com/t/effects-of-a-humongous-controller-on-performance/191715>\
**Category:** Rails\
**Created:** [July 16, 2010, 5:06pm UTC](https://www.ruby-forum.com/t/effects-of-a-humongous-controller-on-performance/191715 "2010-07-16T17:06:50Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gaudimila](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/87869e/32.png) [@gaudimila](https://www.ruby-forum.com/u/gaudimila)\
**Post date:** [July 16, 2010, 5:06pm UTC](https://www.ruby-forum.com/t/effects-of-a-humongous-controller-on-performance/191715/1 "2010-07-16T17:06:50Z")

</div>

I have a client that has a Rails app that was built by someone that  
didn’t know what they were doing, at least from the standpoint of MVC,  
and so rather than portioning out their business logic in different  
controllers, they have a controller with hundreds of methods, totaling  
60,000 lines of code. Yes, 60,000.

They are – not surprisingly – having performance problems. However  
these problems could be elsewhere, there are obviously some other  
problems with this code.

Before I start what will be a very painful and time-consuming  
refactoring effort, I really do need to determine unequivocally that a  
controller this large is really truly certainly a significant  
performance problem. Yes, this should be fixed but at this point I need  
to be in triage mode and know for sure.

My thinking is that perhaps every time a page is rendered, a mongrel has  
to instantiate this controller and that marshalling this into RAM is  
very time-consuming. Or does a controller get loaded into RAM at server  
startup and then the effect is not all that substantial for each page?  
Any ideas on this?

I am familiar with Ruby profiling and we are looking into that too.

Thanks.

---

<div class="post-metadata">

**Author:** ![gaudimila](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/87869e/32.png) [@gaudimila](https://www.ruby-forum.com/u/gaudimila)\
**Post date:** [July 16, 2010, 5:18pm UTC](https://www.ruby-forum.com/t/effects-of-a-humongous-controller-on-performance/191715/2 "2010-07-16T17:18:43Z")

</div>

> My thinking is that perhaps every time a page is rendered, a mongrel has  
> to instantiate this controller and that marshalling this into RAM is  
> very time-consuming. Or does a controller get loaded into RAM at server  
> startup and then the effect is not all that substantial for each page?  
> Any ideas on this?

I’m not familiar with Mongrel-based hosting, but in Passenger classes  
are  
cached in memory when loaded and instantiated from that. The cost of  
instantiating a new object shouldn’t be that onerous (even if you have a  
zillion methods) as it’s only a pointer to the class at that point and  
an  
instance data created during instantiation.

I am familiar with Ruby profiling and we are looking into that too.

> 

Personally I’d recommend testing it on a Mac and using DTrace to get a  
really good insight in to where it’s spending it’s time. I’ve had a lot  
of  
success with that in the past.

Cheers,

Andy

---

<div class="post-metadata">

**Author:** ![gaudimila](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/87869e/32.png) [@gaudimila](https://www.ruby-forum.com/u/gaudimila)\
**Post date:** [July 16, 2010, 5:51pm UTC](https://www.ruby-forum.com/t/effects-of-a-humongous-controller-on-performance/191715/3 "2010-07-16T17:51:30Z")

</div>

Personally I would get hold of the log files and see what methods (or  
at least controller and actions) are being called the most and see  
what sort of time they are taking. The users might be able to tell you  
what appears to be the slowest parts of the system.

Then I would concentrate on those parts of the 60,000 lines of code  
that people are actually complaining about.

You don’t want to be trying to refactor 60,000 lines of code in one  
go. Refactor around the really bad parts, cleaning up as you go.