Hi, In regards to performance, I've found that the EventDispatcher is pretty well optimized, I haven't looked at the code but as you can see from this XHProf run: http://sf2demo.rodb.ro/callgraph.php.png (large image), the 'performance hit' is taken when rendering the page itself. Maybe the performance of EventDispatcher could be further improved but like I've said, I've never looked at it. Keep in mind that XHProf also has a performance impact of about 40% or so (or at least on my system).
Also, from some benchmarking I've did late last week, I've found that when rendering the simple 'Welcome page' against 100 concurrent users, the time is around 2-3 ms with all the tweaks mentioned in the manual. The point of that benchmark was to see what's the performance hit against a simple Silex page. The one in Silex was generally around 0.8ms and when removing the templating from the equation, the performance Symfony was around 1.1ms (rendering the same response but via a simple new Response() call). But this is more of another topic rather that AOP, if you wish, we can surely talk about it on another thread :) Best regards. On Monday, December 3, 2012 9:34:39 AM UTC+2, Stéphane ERARD wrote: > > Like having event dispatcher implemented as an extension, like twig c > extension? > > Is event dispatcher slow anyway? Or anyway room for performance > improvment? > Le 3 déc. 2012 08:26, "Larry Garfield" <la...@garfieldtech.com<javascript:>> > a écrit : > >> Drupal dev here. :-) Drupal has been accused of being "procedural AOP" >> before, and not entirely inaccurately. >> >> Be very careful with that. AOP is a flame thrower; very powerful, but >> can also burn you quite badly. If you're not extremely careful, it can >> make effective unit testing next to impossible. >> >> That's not to say don't use it, but coming from a system that is built >> around AOP principles... I would not recommend baking full-on AOP into >> Symfony. Rather, let's just make events faster so they're cheaper to use. >> >> --Larry Garfield >> >> On 12/03/2012 01:01 AM, Victor Berchet wrote: >> >> Florin, >> >> What a nice rant ! >> >> But as for most rant, only a few lines of you message is relevant (the >> other having been treated in previous message or being non-argument) let me >> handle them: >> >> - "comments": annotation is one way to configure AOP, use php/xml/yml >> if you like, >> - "writing events instead of comments": >> - you can use AOP with 3rd party libs that do not use events >> - you won't have the overhead of dispatching an event if no listeners >> is attached to the events (ie you can logging in your debug environment >> that has 0 impact in your prod env). >> >> As I state in my second message, my intention is more to promote AOP >> than to have something in Symfony. You seem to be this kind of people that >> have problems with (not so) new concepts, you can go read me first message >> again then ! >> >> The only part of your message I like is "I'll change my mind". >> >> For #2679, I don't really see how it relates with AOP nor why it is a >> bug - As a reminder the issue state that http://admin-zone/<any url> >> should return a 403 even if <any url> does not correspond to an existing >> route. It currently returns a 404 if the route does not exist. This is >> because the routing is now triggered before the security, for good reasons. >> >> Cheers, >> Victor >> >> Le dimanche 2 décembre 2012 22:29:55 UTC+1, Florin Patan a écrit : >>> >>> I got a question for you as well as for the rest of the community :) >>> Do you really needed? >>> Is is something that you can't finish your project without? >>> >>> I'm not saying AOP is bad, the main scope is quite nice on paper, >>> academically, but also OLD! Some references for AOP date back to 1994-5. >>> I have to admit, until hearing about it from Victor, I didn't had a clue >>> about it, now I just know what it is but I won't use it. >>> Why? >>> Simple. I don't want more layers of abstractions between my original >>> code and the server. I want to keep it as simple and clean as possible even >>> if it means that I won't be able to write comments that are shorter that >>> the plain old code. Plus, as far as I can tell, I could just as well be >>> using events for my needs instead of comments, or maybe I just didn't got >>> the full view of it. What would that be good for, writing events instead of >>> comments?!? Maybe I just want to have better traceability for the code. >>> Maybe it's better to know that if I write a piece a code, the other people >>> that will come after me when I'm not there, will be able to see __CODE__ >>> not comments or code hidden somewhere else. I want to be able to see what's >>> going to be executed as much as possible. >>> >>> Ok, so there'll be a AOP extension. GREAT! Now convince the sys-admins >>> to install it. More over you know what they'll ask? Is this safe? Does it >>> crash under load? does it block something? Can it have memory leaks? Is it >>> threadsafe? Can't you program without it? >>> And if you've never heard those questions about __ANY__ third party or >>> even PHP extension then either your sys-admins don't care, don't know, do >>> extensive tests and know what you need it for/how it works better that you >>> or you simply didn't worked into a enterprise environment. >>> >>> So we have this already, Doctrine is using annotations, Symfony2 is >>> doing it and so on but the question stands: Do we __REALLY__ need? In the >>> framework? When everyone on the industry wants faster frameworks, easier to >>> use features from the frameworks, a better/faster PHP engine and so on? Is >>> it stopping Symfony2 from being waay faster that Zend Framework2? Is it >>> stopping Symfony2 to be clean and relatively easy to pick up by new people? >>> >>> I know, once you've found a new toy you'll see it used everywhere but >>> you always have to ask yourself: do I really need it here? Is PHP suited >>> for AOP? Do I need a way to change the classes at runtime? Do I need a way >>> to hide the implementation from the programmer who'll then spend hours >>> trying to debug something that he doesn't understand? >>> >>> And maybe the most relevant case, can you explain me __WHY__ do you >>> need it in the framework? And if you are going to say: enforce SRP then >>> please don't. Just because you write it somewhere else then compile it at >>> runtime/cache time and write a comment for it it doesn't mean you got your >>> responsibilities separated, it means that you just managed to perform the >>> illusion of separating the concern to the end user while introducing him to >>> whole new level of where's this executed and why is this not performing >>> what I want??? >>> >>> But I guess we indeed need another layer of abstraction/design >>> pattern/paradigm in PHP, which is supposed to be simple, clean, fast, not >>> like Java, or insert your clearly more preferred language here, which has >>> all those cool features that we can't play with in PHP :( If you like so >>> much coool things, just look at the mess that Zend Framework 2 is. >>> And if you like AOP and want to help, can you debug and fix this please? >>> https://github.com/symfony/symfony/issues/2679 my mortal skills aren't >>> enough to understand the Security component to fix it. >>> >>> Maybe when PHP will have native support for the features needed to do >>> a clean AOP implementation, I'll change my mind (for sure), or maybe that >>> will happen faster then that. Who knows? :) >>> >>> Just my two cents from a non-academic / theoretic point of view. >>> >>> >>> >>> Best regards. >>> >>> >>> >>> On Thursday, September 30, 2010 8:42:16 PM UTC+3, Yuen-Chi Lian wrote: >>>> >>>> Hi, >>>> >>>> I searched the entire group but couldn't find many discussions on AOP. >>>> >>>> The SF2 Security discussion (http://bit.ly/sf2sec) got me to wonder >>>> will AOP ever be part of SF2. If yes, are we going to write it all or we >>>> will use the state-of-art AOP solution in PHP (which is?)? >>>> >>>> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfon...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> symfony-devs...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to symfon...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> symfony-devs...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
