Rencontrer des problèmes de faibles performances avec in_array de PHP

Les performances PHP s'améliorent constamment. Cependant, si vous ne l'utilisez pas correctement ou si vous ne faites pas attention, vous risquez toujours de tomber dans les pièges de l'implémentation interne de PHP. J'ai rencontré un problème de performances il y a quelques jours.

Voici ce qui s'est passé. Un collègue a signalé qu'une de nos interfaces mettait 5 secondes à revenir à chaque fois. Nous avons examiné le code ensemble, et nous avons été « surpris » de constater qu'elle était appelée en boucle (environ 900). fois). Une opération de lecture du cache a été effectuée, mais la clé du cache n'a pas changé, nous avons donc déplacé ce code en dehors de la boucle et testé à nouveau. Le temps de retour de l'interface est tombé à 2 secondes, woohoo ! Même s’il a doublé, ce n’est évidemment pas un résultat que nous pouvons accepter !
La quantité de code à l'origine du problème de performances n'était pas importante. Après avoir éliminé le problème d'E/S, nous avons écrit un morceau de code de test et, bien sûr, le problème est réapparu rapidement.

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

Oui, nous utilisons des numéros de chaîne, et voici à quoi ils ressemblent une fois sortis du cache ! Le voici donc spécialement converti en chaîne (s'il s'agit directement d'un nombre, ce problème ne se produira pas, vous pouvez le vérifier par vous-même). On peut voir que le temps consommé est de 1 seconde, soit seulement 3000 cycles. Le temps système suivant est également destiné à ce que nous n'obtenions aucune information efficace en utilisant strace.

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

us J'ai seulement vu que le délai entre ces deux appels système était très important, mais je ne savais pas ce qui était fait ? Je suis perdu. Heureusement, en plus de strace, les outils de débogage sous Linux incluent également ltrace (bien sûr, il existe également dtrace et ptrace, qui dépassent le cadre de cet article et seront omis).

Citation : strace est utilisé pour suivre les appels système ou la génération de signaux d'un processus, tandis que ltrace est utilisé pour suivre le processus d'appel des fonctions de la bibliothèque (via IBM Developerworks).

Afin d'éliminer les facteurs d'interférence, nous attribuons directement $x à la forme du tableau ("0", "1", "2",...) pour éviter des appels malloc excessifs affectant les résultats. Exécuter

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

Figure 2

us I J'ai vu que la fonction de bibliothèque __strtol_internal est appelée très fréquemment, atteignant 94%, ce qui est trop exagéré. Ensuite, j'ai vérifié ce que fait cette fonction de bibliothèque __strtol_internal. Il s'avère qu'il s'agit d'un alias de strtol. en Conversion en entier long, on peut deviner que le moteur PHP a détecté qu'il s'agit d'un nombre de chaîne, il s'attend donc à les convertir en entier long pour comparaison. Ce processus de conversion prend trop de temps, on exécute à nouveau :

<. 🎜>

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

Vous pouvez facilement intercepter un grand nombre d'appels comme celui illustré ci-dessous. À ce stade, le problème a été trouvé. Cette comparaison lâche in_array convertira d'abord deux chaînes de caractères en entiers longs, puis les comparera. Je ne sais pas à quel point la performance sera bonne.

Maintenant que nous connaissons le nœud du problème, nous avons de nombreuses solutions. La plus simple est d'ajouter le troisième paramètre de in_array à true, ce qui devient une comparaison stricte, tout en comparant les types, cela évite la conversion intelligente des types par PHP, et il s'exécute beaucoup plus rapidement. Le code est le suivant :

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

Beaucoup plus rapide ! ! ! On voit que le temps pris par sys n'a pratiquement pas beaucoup changé. Lorsque nous retraçons, nous devons toujours attribuer $x directement pour éliminer les interférences des appels malloc. Parce que dans notre application actuelle, nous le retirons immédiatement du cache, il n'y a donc pas de boucle comme dans l'exemple de code à appliquer. mémoire.

Exécuter à nouveau

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

Comme indiqué ci-dessous :

__ctype_tolower_loc prend le plus de temps ! J'ai vérifié ce que fait la fonction de bibliothèque __ctype_tolower_loc : la compréhension simple est de convertir les chaînes en minuscules, cela signifie-t-il donc que les chaînes de comparaison in_array ne sont pas sensibles à la casse ? En fait, cet appel de fonction a peu de rapport avec notre in_array. Concernant l'implémentation de in_array, il vaut mieux jeter un oeil au code source de PHP je le comprendrai probablement plus en profondeur

Dans la soirée, J'ai lu le code source PHP 5.4.10 suivant, je suis vraiment intéressé par in_array, haha. Il se trouve à la ligne 1248 de ./ext/standard/array.c. Vous pouvez voir qu'il appelle la fonction php_search_array. ci-dessous ajuste également cela, mais le dernier paramètre est différent ! Après quelques recherches, dans le cas d'une comparaison lâche in_array, il a finalement appelé la fonction zendi_smart_strcmp (vraiment une fonction "intelligente") pour comparaison, située dans ./Zend/zend_operators.c. Nous avons utilisé ltrace pour convertir un grand nombre de données capturées. en entiers. L'opération est le comportement de is_numeric_string_ex.

La fonction is_numeric_string_ex est définie dans ./Zend/zend_operators.h Après un tas de jugements et de conversions, strtol est appelé à la ligne 232, c'est ce que nous avons dit dans l'article The. les fonctions système mentionnées dans, convertissent les chaînes en entiers longs, il y a des images et des faits

Plus de rencontres avec in_array de php Pour les articles liés à problèmes de performances faibles, veuillez faire attention au site Web PHP chinois !