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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
