PHP的性能一直在提高。然而，若是用的不恰當，或是一個不留神，還是可能會踩到PHP內部實現方面的坑的。我在前幾天的一個性能問題上就碰到了。

事情是這樣子的，一位同事反饋我們的一個接口每次返回需要5秒之久，我們一起review了代碼，“驚喜”的發現居然在循環（大約900次）中調用了一個讀緩存的操作，而這個緩存的key并沒有改變，因此我們把這段代碼移到了循環外面，再測，接口返回時間降到了2秒，嗚呼！雖然提升了1倍，但明顯不是我們能接受的結果！
出現性能問題的代碼量并不大，我們排除了IO問題以后，寫了一段測試代碼，果然問題很快重現。

復制代碼 代碼如下:

<?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$ ltrace -e "__strtol_internal" /usr/local/php/bin/php test.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

復制代碼 代碼如下:

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

__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的行為。