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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> > 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 -- 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. -- 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-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.