Small optimization to module_invoke_all()

Makes sense.

@moshe, the function I actually had in mind was field_access() - which calls module_invoke_all() for each field rendered on a page - that can easily run into the hundreds, and it's likely to as we convert more and more things to fields (comment body and subject, comment uploads, node username, taxonomy term fields for each vocabulary etc.)

Not to mention module_invoke_all() is an API function in the critical path which any module can use, so we have no idea what contrib modules will do with it. Just because core currently doesn't call it 3000 times per page, doesn't mean there aren't scenarios in contrib which could cause such a thing to happen.

While we're on 300 comments, I consider Drupal.org statistically significant for performance improvements, even small ones.

Forgot to mention, the ideal thing here would be to remove the check entirely, since module_implements() already runs drupal_function_exists() (but doesn't check the return value - so we can't remove that check at the moment or we risk a lot of fragility in relation to undefined function errors). This information from Berdir in #drupal answering someone else's question, but relevant here.

OK so just to be clear on what the numbers are. In microbenchmarks (1 million iterations, no xdebug), drupal_function_exists() costs three times as much as function_exists().

nothing at all: 0.241947174072 seconds
function no_op() {}: 0.451041936874 seconds
function_exists() 0.640865802765 seconds
drupal_function_exists: 1.68899798393 seconds

We currently call it about 900 times on a front page with 30 comments, and 873 times on user/admin/permissions.

1 million iterations has it as 1.5 seconds more expensive than function_exists(), so 1,000 calls would be ~1.5ms. Even on pages like user/n where it's only called 150-odd times, drupal_function_exists() is still within the top 50 most expensive function calls for self time. Most pages on my laptop render in about 100-200ms (when measured via devel, not when profiling) - so, for every 1,000 pointless calls we remove, we get back ~1% of page execution time, ish. If you combine this with the patches to url(), drupal_lookup_path(), drupal_render(), theme(), check_plain(), some committed, some not, we're looking at in the region of 3-10,000 or so similar removals depending on which page you're looking at - which would tally with the 5% improvement I measured on #513984: Find bottlenecks in HEAD - meta issue.

For comparison, node_load() caching would have got us around a 5-10% improvement in core - see http://drupal.org/node/111127#comment-1147475 / http://drupal.org/node/111127#comment-1495318 - but which requires maintaining the cache properly, a lot of additional code weight to do that, whereas most of these 'micro' patches are less than 1-2k each.

Registry was ripped.