Encountering low performance problem of in_array in php_PHP tutorial

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.

Here’s what happened. 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 cache read operation was performed, but 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 piece of test code, and sure enough, the problem reappeared quickly.

Copy code The code is as follows:

$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-type numbers, and this is what they look like when taken out from 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



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 is for. It turns out to be an alias of 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, so we execute it 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 picture 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.



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 true, which becomes a strict comparison, while also To compare types, this avoids PHP's clever conversion of types, and it runs much faster. The code is as follows:

Copy code The code is as follows:

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

for($i=0;$i<3000;$i++){
                                                                                                                                                                                                        🎜>?>

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 time taken by sys 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 of the cache at once, so there is no loop like in the sample code to apply for memory.
Execute again

Copy the 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, which is The system function we mentioned in the article converts a string into a long integer, there are pictures and the truth

http://www.bkjia.com/PHPjc/313618.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/313618.htmlTechArticlePHP’s performance 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 had a performance problem a few days ago...