遭遇php的in_array低效能問題

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

我們只看到這兩次系統呼叫之間的延遲非常大，卻並不知道做了什麼？一籌莫展了，幸好，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

我們看到庫函數__strtol_internal的呼叫非常之頻繁，達到了94%，太頻繁，達到了94%，太頻繁，達到了94%，太頻繁，達到了94%，太頻繁誇張了，然後我又查了一下這個函式庫函數__strtol_internal是乾嘛的，原來是strtol的別名，簡單的說就是把字串轉換成長整形，可以猜測PHP引擎已經偵測到這是一個字串型的數字，所以期望將他們轉換成長整型來比較，這個轉換過程中消耗了太多時間，我們再次執行:

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

可以輕鬆抓到大量下圖這樣的調用，到此，問題找到了，in_array這種鬆比較，會將兩個字元型數字字串先轉換為長整型再進行比較，卻不知效能就耗在這上面了。

知道了癥結所在，我們解決的辦法就很多了，最簡單的就是為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

如下圖:

__ctype_tolower_loc佔用了最多的時間！查了一下函式庫函數__ctype_tolower_loc是幹嘛的：簡單的理解是將字串轉換成小寫，那麼這說明in_array比較字串不區分大小寫嗎？其實這個函數呼叫已經跟我們這個in_array感覺聯繫不大了，關於in_array的實現，還是去看看PHP的源碼，大概理解的更為透徹了

晚上又翻了以下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的行為。

函數is_numeric_string_ex是在./Zend/zend_operators.h中定義的，在前面進行了一堆的判斷和轉換之後，在232行調用了strtol，就是我們在文章中提到的系統函數了，將字串轉換成長整型，有圖有真相

更多遭遇php的in_array低效能問題相關文章請關注PHP中文網！