Bug Report #919
Event::add performance enhancement/behavior fix
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | Urgent | Due date: | ||
| Assignee: | % Done: | 100% |
||
| Category: | Core | |||
| Target version: | 2.4 | |||
| Resolution: | fixed | Points: |
Description
Currently, the Event::add function checks to make sure the callback does not exist for the event before it is added. it will return FALSE if it already exists and not add it again, otherwise will add it and return TRUE.
However, this behavior is undocumented. I believe that instead of checking and not adding the event, it should simply be added whether or not it exists already. All event systems I know of work like this (e.g. Javascript). Because this behavior is not documented and the require_once nature of PHP, I do not think that this change would affect many people, if any. If you want to maintain this ability I propose doing so with an additional "unique" argument. E.g:
1 Event::add('system.display','my_callback'); //adds
2 Event::add('system.display','my_callback'); //adds
3 Event::add('system.display','my_callback',true); //does not add
My patch includes this new argument as described above.
Some may argue that 30 is not a realistic number, but I think it is best to make *any* aspect of the system scalable and let the users decide how they want to use it. I have attached a patch that makes this simple change. Please consider it and I'd love to discuss this if everyone is not in agreement.
Related issues
Associated revisions
Allow duplicate event-callbacks, avoiding array search when unnecessary. Fixes #919
History
Updated by Colin Mollenhour about 3 years ago
Just in case it wasn't clear, this change will make adding callbacks require 0 string comparisons vs (n-1)*n in the worst case for n callbacks. That's O(0) vs almost O(n^2), two orders of magnitude faster. :)
Updated by Jeremy Bush over 2 years ago
- Status changed from New to Assigned
- Assignee changed from Jeremy Bush to Chris Bandy
- Priority changed from High to Urgent
- 11 set to 2.3.4
Updated by Chris Bandy over 2 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
Applied in changeset r4462.
Updated by Chris Bandy over 2 years ago
- Resolution set to fixed