Encountering low performance issues with PHP's in_array

PHP performance is constantly improving. 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

The performance of PHP has been improving. 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.

The thing is like this. A colleague reported that one of our interfaces took 5 seconds to return each time. We reviewed the code together, and we were "surprised" to find that it was called in a loop (about 900 times). A read cache operation was performed, and the cache key did not change, 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 that caused the performance problem was not large. After we eliminated the IO problem, we wrote a test code, and sure enough, the problem reappeared quickly.

Copy code 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)){ 
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, and this is what they look like when taken out from the cache La! 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



us I only saw that the delay between these two system calls was very large, but I didn't know what was done? 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

As shown in Figure 2




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

Copy code The code is as follows:

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

can easily catch a large number of calls like the one below. At this point, the problem has been found. The loose comparison of in_array will convert two character numeric strings first. Compare the long integer type again, but I don’t know that the performance is consumed on this.



Knowing the crux of the problem, we have many solutions. The simplest one is to add the third parameter to in_array to true, which becomes a strict comparison, while also To compare types, this avoids PHP's clever conversion types, and it runs much faster. The code is as follows:

Copy code 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;
        }
}
?>

Copy code The code is as follows:

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

Copy code The code is as follows:

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. Okay, I can’t go on. Welcome to communicate with me. , please correct me if I write something wrong.

——————2013.08.29 dividing line——————————

I read the following source code of PHP 5.4.10 in the evening, and I am interested in in_array It’s so big, haha. It’s 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, that is The system function we mentioned in the article converts a string into a long integer. There are pictures and the truth

Related recommendations:

Once again, I encountered garbled characters

when PHP inserted Chinese into MYSQL and displayed it.

The above is the detailed content of Encountering low performance issues with PHP's in_array. For more information, please follow other related articles on the PHP Chinese website!