Shulou(Shulou.com)06/03 Report--

This article focuses on "how to solve the in_array low performance problem of php". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to solve the low performance problem of in_array in php.

The performance of PHP has been improving. However, if you use it improperly, or if you are not careful, you may step into a hole in the internal implementation of PHP.

The copy code is as follows:

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

Real 0m1.132s

User 0m1.118s

Sys 0m0.015s

Yes, we use string numbers, and that's what happens when you get it out of the cache! So here is deliberately converted to a string (if it is directly a number, this problem will not occur, you can verify it yourself). You can see that the time took 1 second, only 3000 cycles, and the later sys is doomed that we won't get any valid information when we use 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 we don't know what has been done. There is nothing I can do. Fortunately, the debugging tools under Linux include strace and ltrace (and, of course, dtrace,ptrace, which is beyond the scope of this article, omitted).

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

To eliminate interference, we directly assign $x to array ("0", "1", "2", …) to avoid too many malloc calls affecting the result.

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

As shown in figure 2

We see that the call to the library function _ _ strtol_internal is very frequent, reaching 94%, which is too exaggerated. Then I checked what the library function _ _ strtol_internal does. It turns out that it is an alias for strtol. To put it simply, it is to transform the string into growing and shaping. It can be guessed that the PHP engine has detected that this is a string number, so I expect them to be converted into growing integers for comparison. This conversion takes too much time, so let's do it again:

The copy code is as follows:

Shell$ ltrace-e "_ _ strtol_internal" / usr/local/php/bin/php test.php

You can easily catch a large number of calls like the following figure. At this point, the problem is found. The loose comparison of in_array will first convert two character-type numeric strings into long integers and then compare them, but do not know that the performance is wasted on this.

Knowing the crux of the problem, we have many solutions. The simplest thing is to add the third parameter true to in_array, that is, to make a strict comparison, and to compare types at the same time, so as to avoid the smart conversion type of PHP, which runs much faster. The code is as follows:

The copy code is as follows:

The copy code is as follows:

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

Real 0m0.267s

User 0m0.247s

Sys 0m0.020s

It's many times faster! You can see that there is little change in sys time. When we ltrace again, we still need to assign $x directly to eliminate the interference of malloc calls, because our actual application is pulled out of the cache at once, so there is no such loop in the sample code to apply for memory.

Execute again

The copy 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! Check out what the library function _ _ ctype_tolower_loc does: the simple understanding is to convert strings to lowercase, so does this mean that in_array comparison strings are not case-sensitive? In fact, this function call does not have much to do with our in_array, about the implementation of in_array, or to see the source code of PHP, probably a more thorough understanding, well, can not go on, welcome to communicate with me, write the wrong place, please correct more.

-2013.08.29 split line-

In the evening, I turned over the following PHP 5.4.10 source code. I am really interested in in_array. Haha, on line 1248 of. / ext/standard/array.c, you can see that he called the php_search_array function. The following array_serach is also tuned, 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 (sure enough, a "smart" function) for comparison, at. / Zend/zend_operators.c, we caught a large number of conversion to integer operations with ltrace is the behavior of that is_numeric_string_ex.

The function is_numeric_string_ex is defined in. / Zend/zend_operators.h. After a lot of judgment and conversion, strtol is called on line 232, which is the system function we mentioned in the article. The string is converted into an integer.

At this point, I believe you have a deeper understanding of "how to solve the in_array low performance problem of php". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.