-- nuxwin <[email protected]> wrote (on Thursday, 27 September 2012, 03:22 AM -0700): > The problem mentionned here is clearly reflected by the > Zend\Mvc\View\Http\ViewManager class. > When I see the numerous nested listeners that are registered on the > bootstrap event, and also, the number of involved objects loaded potentially > for nothing , I'm posing some questions about possible overhead and zf2 > performances...
Profile it. Attaching listeners is negligible in terms of overhead. The number of objects we load is potentially concerning, and we're trying to evaluate how much of an impact that has. My point, though, is not to make assumptions based on what you _think_ could be an issue -- you need to profile the code to see what's actually consuming resources. > Well the DI is not a rescue here but I did preferred see a delayed > configuration/registration instead of a > pre-configuration/pre-registration.. To resume, by reading the MVC > code part of zf2 you will see that even without your own listeners you > have a bunch of work that is done for each request and unfortunately, > potentially (surely) for nothing. Again, you're not profiling, you're making assumptions. Registering listeners is really, really cheap. Triggering the listeners is quite cheap as well (we use SplPriorityQueue internally, which makes looping through the listeners very fast; triggering a listener is simply a method call usually). Even with DI, listeners were being registered -- they were simply happening in a different location. It wasn't deferred or delayed -- you need the listeners in place before the various events are triggered. I find it interesting that you'd think DI would help here -- in fact, it had the opposite effect. The performance was horrible, and it made it so that event registration was happening in a context that often wasn't semantically close to what needed to happen. Finally, configuration _is_ delayed currently. Modules are loaded, aggregating configuration, and then the configuration occurs. This ensures that once we start working with the SM and events, we know that it will not change. My main point is this: before making assumptions about the performance of the code, please do some profiling, and also ask around as to why certain decisions were made. The decisions are not made in a vacuum, and there are typically mailing list threads, meeting minutes, and more that we can point you at. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- List: [email protected] Info: http://framework.zend.com/archives Unsubscribe: [email protected]
