Re: Are there performance overheads to RequestAction?

[Felix Geisendörfer]

Hi johnwik, I think the problem with requestAction is not the dispatching alone. There is a good bit of things happening, just to name a view: Dispatcher Dispatcher does routing Dispatcher figures out what (Plugin)/Controller/Action is request Dispatcher loops through all $paths->controllerPaths files, to figure out what Controller to load (if you request one you haven't requested before) Comment: None of this is necessary when you use requestAction. You know what exact controller/action you need. No request<->php interface for this is needed recursive functions get called twice (stripslashes_deep, see Dispatcher::parseParams() ) Lot's of regex get's executed again (finding webroot, base, etc.) Comment: Some of this stuff is necessary to parse the params correctly, but most of it is overhead you only need when rendering the first Controller action in your script execution. Controller setup Once the dispatcher has figured out what Controller you want to use, the following things get executed over and over again for every requestAction, even if you call the same controller again. All Controller Models get loaded and referenced as Controller variables (Note: I think the ClassRegistry keeps record of previously created class instances, which is good) All Components get re-instanced over and over again All filter's (before, after, beforeRender) get executed Comment: I think for a good deal of things requestAction is beeing used right now, some of the stuff above in unnecessary, however avoiding some of it by default could lead to confusion and strange behavior. So I'm not trying to say that requestAction should be avoided, nor that it is bad. But I think doing a fair performance test on it, vs. other approaches would be hard to setup because it's difficult to say what of the stuff above is definitely unnecessary and what isn't. And depending on this decision results could be pretty different. Side Note: I've written the stuff above from my understand of the dispatching process and only looked in the core code a couple times, so some of it might not be completely correct. My advice to people who are concerned about performance, is to think about what they are using requestAction for right now, and to try to figure out if some of it should be moved to the AppController. This will always be the better and faster solution if you have something like a menu, that you need to have rendered for every request. At least it is to me. I think requestAction is more of a problem when you are working with plugins that are supposed to be independent from the AppController setup like I do. Because in that case you might end up with something like 15-20 requestActions / execution which is definitely too much overhead for me. Right now I'm running with my own solution for the problem which I mentioned in my earlier post, but I definitely want to talk to one of the devs about it when I (and they) find time to. Anyway, I hope that stuff above is useful when you try to get your own idea about the overhead caused by requestAction. Best Regards, Felix Geisendörfer -------------------------- http://www.thinkingphp.org http://www.fg-webdesign.de johnwik schrieb: Hi! I am also using actionRequest to render several different controllers from within a main controller and I have noticed that the dispatcher is called for each call to a controller. I haven't done any real testing yet so I'm not sure about the performance. Is there a way to reuse the Dispatcher and Controller for several user controllers and plugins? I'm also thinking about extending the Dispatcher or the Controller with a class that should be globally accessible by the user controllers and views. Any comments on that? At the moment I am experimenting with creating a private singleton class in the AppController that is extended by public accessible classes such as Request, Response, Security etc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---