[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