Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Fairly minor, but adds in an extra function_exists (since already know function exists due to the module_implements))/call_user_func_array.
| Comment | File | Size | Author |
|---|---|---|---|
| flag-flag_link_types-module-invoke.patch | 647 bytes | hefox | |
Comments
Comment #1
joachim CreditAttribution: joachim commentedNew features go on the 3.x branch.
Though also, is this really going to be much of a performance gain? On D7 at least this is a hook whose results are cached, so the hook only gets invoked on cache clears. Or is that why you've filed it on 6.x-2.x?
The cost though, I think, is code clarity: I think module_invoke() looks clearer than building the function names.
If the performance *is* improved on D6 by this, I'd like this with a comment explaining why we're eschewing the API.
Comment #2
hefox CreditAttribution: hefox commentedFor flag specially, it's a performance gain defiantly, whether one that's any way noticeable, no. However, it's case of little things that build up -- combining it together with other instance of similar, it is.
As far as using api goes, in d6 at least module_invoke_all doesn't use module_invoke, neither does node_invoke_nodeapi, comment_invoke_comment, and menu_router_build. They all use module_implements + $function or call_user_func. There are a few that use module_invoke, but seem more the outliers than not, (and a few really bad apples like user_module_invoke #1861562: Use module_implements('user') instead of module_list()/function_exists (for performance)).
As far as filling it against 6.x, I figured it'd be a won't fix, and so rolled it against the version I had. So, considering above, won't fix or shall I roll it for real?
Comment #3
joachim CreditAttribution: joachim commented> in d6 at least module_invoke_all doesn't use module_invoke, neither does node_invoke_nodeapi, comment_invoke_comment, and menu_router_build.
Anything with 'invoke' is part of the invoking API as I see it, so it can do whatever it likes in its internals. This is not the case here.
If you're desperate to speed this up, I'd rather we backported the full caching that 7.x-3.x has, starting with 7.x-2.x. The module_invoke() can then stay, as it is only called on a full cache clear.