Doing some research I noticed that module_hook_info() keeps a cache entry that is superseeded by the module_implements() code in 99% of the use cases.
This cache sounds quite a bit useless.
But going deeper I noticed this actually was being used by the module_hook() function.
Deeper and deeper again I noticed that module_hook() was duplicating the module_implements() code since it's requiring the group related PHP file for modules.
So I did a simple patch that removes all the static and remote cache of the module_hook_info() function and simplifies the module_hook() function reducing it to two lines of code only.
Verified pros:
- This brings some minor performance improvements on the site I tested it: best case scenario faster run, worst case scenario it gets rid of a useless remote cache query and has no impact on runtime
- Less cache means less complexity
module_hook() function is a lot simpler too
Unverified cons:
- When someone calls
module_hook() outside of module_invoke_all() this can bring a performance penalty since module_implements() will load all the PHP files for the group, but note that most people will actually do that after iterating over module_implements() so this is not really a penalty, at least not in 90% of use cases.
- It will penalize modules using the
module_hook_info() function directly: but let's be honest here, any module doing that is clearly doing it wrong and should be fixed.
Comments
Comment #1
pounardI didn't do extensive testing thought, just installed a basic site and played with it, so I'd be curious to see what tests results will give in return.
Comment #2
pounardThis works quite nicely on my end. Is there someone curious enough for profiling this on various sites to see how ti behaves ? I'll do the same on some projects of my own.