[wp-hackers] apply_filters, merge_filters and reset()
Jacob
wordpress at santosj.name
Fri Nov 9 14:12:43 GMT 2007
Ryan Boren wrote:
> On 11/8/07, Jacob <wordpress at santosj.name> wrote:
>
>> Hmm, I believe my usage of foreach was to use the $value of the first
>> foreach (since it is the array) instead of doing your method. I was able
>> to confirm that, at the very least, it doesn't break anything on the
>> trunk. I would rather use foreach than while since it looks cleaner.
>>
>> If you want to take care of 2.3.x, I'll submit a patch for 2.4. There
>> are some other areas I want to clean up in the trunk.
>>
>
> I think we used to do a foreach. A switch was made to do-while-next
> because it was supposedly faster. I don't really care what the loop
> looks like as long it is as fast as can be. apply_filters is called
> hundreds of times. Any changes need to be profiled.
>
> Ryan
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
Well, I think cleaning the code up would cut some of the branching,
which would speed things up. Some things I've noted.
1. Is the key sorting of $wp_filter[$tag] really necessary? I don't
think so. Removing the whole merged_filters variable could speed up a
portion where apply_filters is first called. I would make a guess and
say that most filters are only called once. Which would boost the speed.
You would cut the branch (+1), cut out three function calls (reset,
uksort, and strnatcasecmp), and a few assignments.
2. Moving the "Do 'all' actions first into its own function will slow
things down, since it is an additional user function call, but having
the code in one place would make the code cleaner and any changes
easier. The cost would be minimal. You could even keep the branch for
checking and put all the rest of the code in a function. That way, the
cost for calling the function is only applied if the 'all' hook exists.
3. @$wp_current_filters[] = $tag is really damn slow. Not the
assignment, the '@' character. I don't know what warning or notice it is
supposed to suppress, but it would be quicker it is was taken out. If
you need to, just check that $wp_current_filter is an array and make it
one if it isn't.
4. Have $wp_current_filter[] = $tag; after the check to see if the tag
exists. As well as calling the 'all' hook. There is no point of
executing everything if it doesn't exist. Although, calling the all hook
might be to say that it could test to make sure that the tag has any
values, which could be used for debugging, but whether the hook exists
or not is not directly passed to the all hook, so the hook would have to
test for it on their its own. (using has_filter).
5. When is $args ever going to be empty? I know, when the all tag
doesn't exist. However, both need it, so it can be placed outside the
all hook branch, so that there wouldn't need to be a check for it, which
would be executed for about 99.99% of users. Moving it from the branch,
would save some time spent executing 'empty' function. (for
apply_filters()).
--
Jacob Santos
http://www.santosj.name - blog
http://wordpress.svn.dragonu.net/unittest/ - unofficial WP unit test suite.
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers
mailing list