Encountering low performance issues with PHP's in_array

PHP performance is improving all the time. However, if you use it improperly or if you are not careful, you may still step into the pitfalls of PHP's internal implementation. I encountered a performance problem a few days ago.

This is what happened. A colleague reported that one of our interfaces took 5 seconds to return each time. We reviewed the code together and were "surprised" to find that a read cache was called in the loop (about 900 times). operation, but the cached key has not changed, so we moved this code outside the loop and tested again. The interface return time dropped to 2 seconds, woohoo! Although it has doubled, it is obviously not a result we can accept!
The amount of code where the performance problem occurred was not large. After we eliminated the IO problem, we wrote a piece of test code, and sure enough, the problem reappeared quickly.

<?php 
$y="1800"; 
$x = array(); 
for($j=0;$j<2000;$j++){ 
$x[]= "{$j}"; 
} 

for($i=0;$i<3000;$i++){ 
if(in_array($y,$x)){ 
continue; 
} 
} 
?>

shell$ time /usr/local/php/bin/php test.php

real 0m1.132s
user 0m1.118s
sys 0m0.015s

Yes, we are using string numbers, This is what it looks like when taken out of the cache! So here it is specially converted into a string (if it is a number directly, this problem will not occur, you can verify it by yourself). It can be seen that the time consumed is 1 second, which is only 3000 cycles. The subsequent sys time is also destined that we will not get any effective information using strace.

shell$ strace -ttt -o xxx /usr/local/php/bin/php test.php
shell$ less xxx

We only see that the delay between these two system calls is very large, But you don’t know what you did? I am at a loss. Fortunately, in addition to strace, the debugging tools under Linux also include ltrace (of course, there are also dtrace and ptrace, which are beyond the scope of this article and will be omitted).

Quote: strace is used to track the system calls or signal generation of a process, while ltrace is used to track the process of calling library functions (via IBM developerworks).

In order to eliminate interference factors, we directly assign $x to the form of array(“0″,”1″,”2″,…) to avoid excessive malloc calls affecting the results. Execute

shell$ ltrace -c /usr/local/php/bin/php test.php

Figure 2

We see that the library function __strtol_internal is called very frequently, reaching 94%, too Exaggerated. Then I checked what this library function __strtol_internal does. It turns out to be an alias for strtol. Simply put, it converts a string into a long integer. It can be guessed that the PHP engine has detected that this is a string type. Numbers, so we hope to convert them into long integers for comparison. This conversion process consumes too much time. We execute again:

shell$ ltrace -e "__strtol_internal" /usr/local/php/bin/php test.php

We can easily catch a large number of calls like the picture below. At this point, the problem is found, in_array For comparison, the two character strings will be converted into long integer types before comparison, but I don't know that the performance is consumed in this.

Now that we know the crux of the problem, we have many solutions. The simplest one is to add the third parameter to in_array to be true, which means it becomes a strict comparison and also compares types. This avoids PHP being too clever. Converting the type is indeed much faster. The code is as follows:

<?php
$y="1800";
$x = array();
for($j=0;$j<2000;$j++){
        $x[]= "{$j}";
}
for($i=0;$i<3000;$i++){
        if(in_array($y,$x,true)){
                continue;
        }
}
?>

shell$ time /usr/local/php/bin/php test.php 

real 0m0.267s 
user 0m0.247s 
sys 0m0.020s

Many times faster! ! ! It can be seen that the sys time consumption has hardly changed much. When we ltrace again, we still need to assign $x directly to eliminate the interference of malloc calls. Because in our actual application, we pull it out from the cache at once, so there is no such loop in the sample code to apply for memory.
Execute again

shell$ ltrace -c /usr/local/php/bin/php test.php

As shown below:

__ctype_tolower_loc takes up the most time! I checked what the library function __ctype_tolower_loc does: the simple understanding is to convert strings into lowercase, so does this mean that in_array comparison strings are not case-sensitive? In fact, this function call has little connection with our in_array. Regarding the implementation of in_array, it is better to take a look at the source code of PHP. I will probably understand it more thoroughly

In the evening, I read the following source code of PHP 5.4.10. in_array is so interesting, haha, located at line 1248 of ./ext/standard/array.c, you can see that it calls the php_search_array function. The array_serach below also adjusts this, but the last parameter is different! After some tracking, in the case of in_array loose comparison, he finally called the function zendi_smart_strcmp (really a "smart" function) for comparison, located in ./Zend/zend_operators.c. We used ltrace to convert a large number of captured data into integers. The operation is the behavior of is_numeric_string_ex.

The function is_numeric_string_ex is defined in ./Zend/zend_operators.h. After a bunch of judgments and conversions, strtol is called on line 232, which is the system function we mentioned in the article. Convert the string into a long integer, there are pictures and the truth

For more articles related to the low performance problem of in_array in PHP, please pay attention to the PHP Chinese website!