Analysis on the Event subsystem

85 views
Skip to first unread message

Christiaan Titos Bolivar

unread,
Jun 18, 2013, 12:30:26 PM6/18/13
to cakeph...@googlegroups.com
Hi everyone,

We are a group of 4 Computer Science students at the Delft University of Technology (Netherlands). For our Software Architecture course (@DelftSWA), students were supposed to choose an open source project on Github and analyze its architecture (based on some weekly assignments, like making a stakeholder analysis, and creating several views of the architecture). We chose CakePHP.

Another goal of the course is to contribute to the project in some way. We had email contact with Mark Story and he suggested that we take a look at the event subsystem. As the course is about Software Architecture, the nature of our contribution is more analytical than actual implemented code.

The results of our analysis can be found here:

https://github.com/erik-am/cakephp/wiki/The-Events-System-of-CakePHP

In our analysis, we first explain what the differences are between old versions of CakePHP and the current version, we include some profiling results, and then we describe the problem and  some possible solutions/observations. Keep in mind, we only had about a two months to get familiar with the code and architecture, so there might be some small things that we missed, but we think we got most of it.

We hope that this document can give you some ideas or insights about how to improve the event subsystem in future versions of CakePHP.

- Erik Ammerlaan @erik-am
- Roshan Timal @ntimal
- Christiaan Titos Bolivar @ChrisTitos
- Wilco Wisse @wilcowisse



PS. We want to give you compliment for the quality of the documentation. Without it, I doubt we could have dove this deep into the code this fast. Projects of other teams in the course we're in much worse shape :P

Jamie Nay

unread,
Jun 19, 2013, 12:45:18 PM6/19/13
to cakeph...@googlegroups.com
I have to compliment you - this is a fantastic analysis of the differences between the old and new event/callback systems. Great job!

- Jamie
--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Jose Diaz-Gonzalez

unread,
Jun 19, 2013, 12:46:29 PM6/19/13
to cakeph...@googlegroups.com
Hi Christian,

I just quickly read through this, and it seems to be a very good overview of our callback system. Hell, I think it would even be neat if this - or a similar writeup on another part of CakePHP - was presented at CakeFest.

This actually goes against my intuitions, given that I've profiled applications that use CakeEvent and have upgraded apps to 2.1 with a subsequent performance loss in certain areas. That said, it's awesome to see that there are definite performance changes we can implement, and even better to know that CakeEvent is not the sole source of performance degradations.

For those who don't see performance numbers, here they are:


I'd also be interested in seeing the application itself, just in case there is something you are doing that isn't exactly kosher. This would definitely make sense to make as part of some sort of benchmark suite as we move towards Cake 3.

All in all, bravo on the writeup, and I'm glad to see that the docs - something everyone complains about - were useful in your case. Hope your team gets high marks!

Jose (little jose, not to be confused with the handsome Jose Lorenzo)



--

mark_story

unread,
Jun 19, 2013, 12:51:59 PM6/19/13
to cakeph...@googlegroups.com
Awesome stuff! This is far more in-depth than I would have ever done. I think your conclusions about ObjectCollection being a bit of a mess and having too many edge cases are spot on.

In the past both on this mailing list and in IRC the idea of only firing/binding events that are actually implemented has come up. It would be interesting to see if the time spent reflecting/determining whether or not callbacks existed or not could offset the time spent invoking methods.

-Mark

José Lorenzo

unread,
Jun 19, 2013, 3:19:21 PM6/19/13
to cakeph...@googlegroups.com
I think that doing the reflection once and then caching it to avoid constructing objects without callbacks will definitely present some sort of performance gain. I'd like to investigate that option in the near future.

Anyone on this list willing to explore a similar solution and come up  with a patch?


--

tgt...@gmail.com

unread,
Jun 19, 2013, 4:41:01 PM6/19/13
to cakeph...@googlegroups.com
Thanks all for your nice comments so far. We are glad that you appreciate our efforts.

We quickly considered Reflection during our analysis, but, frankly, we missed the simple fact that those results could of course be cached. That should almost certaintly pay off, assuming that a look-up in the cache would be fast.

However, I think this will be easier to implement and also more effective, if events are no longer relayed through the ObjectCollection. Because if one would implement reflection in the current situation, then only the ObjectCollection would be able to determine which Behaviors/Components/Helpers actually implement a certain event. Therefore, for each dispatched event, there still needs to be a call to ObjectCollection->trigger(), which might be in vain.


Op woensdag 19 juni 2013 21:19:21 UTC+2 schreef José Lorenzo het volgende:

mark_story

unread,
Jun 23, 2013, 9:57:30 PM6/23/13
to cakeph...@googlegroups.com
Thanks again for doing the research and coming up with some suggestions. I've put together a wiki page with some changes I think would help address some of the issues you outlined.


Let me know if I've missed anything or if there are other issues we should be fixing.

-Mark

On Tuesday, 18 June 2013 12:30:26 UTC-4, Christiaan Titos Bolivar wrote:
Reply all
Reply to author
Forward
0 new messages