Hi felix
"
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"
how are you doing that ? currently I have menus that are in every page,
and I use requestAction in the layout to do that.
olivvv
Felix Geisendörfer wrote:
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
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 -~----------~----~----~----~------~----~------~--~---
|