您当前位于: 首页 » 我爱PHP » 遭遇php的in_array低性能

遭遇php的in_array低性能08/28/2013

PHP的性能一直在提高。然而,若是用的不恰当,或是一个不留神,还是可能会踩到PHP内部实现方面的坑的。我在前几天的一个性能问题上就碰到了。

事情是这样子的,一位同事反馈我们的一个接口每次返回需要5秒之久,我们一起review了代码,“惊喜”的发现居然在循环(大约900次)中调用了一个读缓存的操作,而这个缓存的key并没有改变,因此我们把这段代码移到了循环外面,再测,接口返回时间降到了2秒,呜呼!虽然提升了1倍,但明显不是我们能接受的结果!

出现性能问题的代码量并不大,我们排除了IO问题以后,写了一段测试代码,果然问题很快重现。

< ?php
$y="1800";
$x = array();
for($j=0;$j&lt;2000;$j++){
        $x[]= "{$j}";
}
 
for($i=0;$i&lt;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

对的,我们用的就是字符串型的数字,从缓存拿出来就是这样子的啦!所以这里是特意转成字符串的(如果直接是数字,并不会出现这个问题 ,各位可以自行验证)。可以看出时间耗掉了1秒,才3000次循环,后面的sys用时也注定我们用strace不会拿到什么有效信息。


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

in_array.strace

我们只看到这两次系统调用之间的延时非常大,却并不知道干了什么?一筹莫展了,幸好,Linux下的调试利器除了strace还有ltrace(当然还有dtrace,ptrace,不在本文讨论范围了,略去)。

引用:strace用来 跟踪一个进程的系统调用或信号产生的情况,而 ltrace用来 跟踪进程调用库函数的情况(via IBM developerworks)。

为了排除干扰因素,我们将$x直接赋值为array(“0″,”1″,”2”,……)的形式,避免过多的malloc调用影响结果。执行


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

如图2
in_array.ltrace1
我们看到库函数__strtol_internal的调用非常之频繁,达到了94%,太夸张了,然后我又查了一下这个库函数__strtol_internal是干嘛的,原来是strtol的别名,简单的说就是把字符串转换成长整形,可以猜测PHP引擎已经检测到这是一个字符串型的数字,所以期望将他们转换成长整型来比较,这个转换过程中消耗了太多时间,我们再次执行:

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

可以轻松抓到大量下图这样的调用,到此,问题找到了,in_array这种松比较,会将两个字符型数字串先转换为长整型再进行比较,却不知性能就耗在这上面了。
tu3

知道了症结所在,我们解决的办法就很多了,最简单的就是为in_array加第三个参数为true,即变为严格比较,同时还要比较类型,这样避免了PHP自作聪明的转换类型,跑起来果然快多了,代码如下:

<?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

快了好多倍啊!!!可以看到sys耗时几乎没有太大变化。我们再次ltrace一把,还是要把$x直接赋值,排除malloc调用的干扰,因为我们实际应用中是从缓存里一次拉出来的,所以也不存在示例代码中这样的循环来申请内存的情况。
再次执行

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

如下图:

in_array.ltrace2

__ctype_tolower_loc占用了最多的时间!查了一下库函数__ctype_tolower_loc是干嘛的:简单的理解是将字符串转换成小写,那么这说明in_array比较字符串不区分大小写吗?其实这个函数调用已经和我们这个in_array感觉联系不大了,关于in_array的实现,还是去看看PHP的源码,大概理解的更为透彻了,好了,没法往下说了,欢迎与我交流,写的不对的地方请多多斧正。
———————2013.08.29分割线——————————
晚上又翻了以下PHP 5.4.10的源码,对in_array的兴趣真大啊,哈哈,位于./ext/standard/array.c的第1248行,可以看到他调用了php_search_array函数,下面的array_serach也是调的这个,只是最后一个参数不同!经过一番跟踪,在in_array松比较的情况下,他最终调用的函数 zendi_smart_strcmp(果然是个“聪明”函数)进行比较,位于./Zend/zend_operators.c,我们用ltrace抓到的大量转换成整型的操作就是那个is_numeric_string_ex的行为。屏幕快照 2013-08-29 23.13.20

函数is_numeric_string_ex是在./Zend/zend_operators.h中定义的,在前面进行了一堆的判断和转换之后,在232行调用了strtol,就是我们在文章中提到的系统函数了,将字符串转换成长整型,有图有真相
zend_operators-is_num

一切柳暗花明?

| 8条评论 标签:  

8条评论
  1. deminy说道:

    这是一个代码设计方面的问题。当面对大数组查询的时候,在PHP中应该尽量采用key查询而不是value查询。函数in_array的性能是不好的。

    所以文中的例子代码如果改为下面的,应该会快很多:

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

    for($i=0;$i

    总之,大数组查询,用in_array函数是个糟糕的选择。应该尽量用isset函数或array_key_exists函数来替代 。in_array函数的复杂度是O(n),而isset函数的复杂度是O(1)。

  2. mxm145说道:

    受教了,看来看函数还是要看全所有的参数。我都不知道还有个true参数

  3. maxdo说道:

    in_array的源码实现里用的是while循环的,而使用array_flip以后,能用上PHP的hash table,这将让复杂度大大降低

  4. bandit说道:

    有个疑问,执行time命令那一步,系统的执行时间只有0.02秒,为什么strace出来的系统两次调用却有4秒多?

  5. 轩脉刃说道:

    赞~打破沙锅问到底的精神

  6. wang说道:

    大数据都不要用in_array,要么isset($arr[$key]),要么strpos,各有千秋,速度和in_array完全不是一个档次

发表评论