Pourquoi === est-il plus rapide que == en PHP?


168

Pourquoi est-il ===plus rapide qu'en ==PHP?


40
C'est plus rapide, mais est-ce beaucoup plus rapide?
Piskvor a quitté le bâtiment

19
Veuillez ne pas lire ce qui est plus rapide en php. Découvrez comment obtenir des données intéressantes dans une seule requête SQL sans abuser des JOIN.
Kamil Szot

15
À qui il pourrait être intéressé par le même sujet === vs ==, mais en JAVASCRIPT, peut lire ici: stackoverflow.com/questions/359494/…
Marco Demaio

5
@Piskvor, ce n'est pas la question
Pacerier

6
@Pacerier: Bon point - c'est pourquoi je n'ai fait que commenter cela. Cela ne répond pas à la question, mais fournit une perspective à ce sujet.
Piskvor a quitté le bâtiment le

Réponses:


200

Parce que l'opérateur d'égalité ==contraint, ou convertit, le type de données temporairement pour voir s'il est égal à l'autre opérande, alors que ===(l'opérateur d'identité) n'a pas besoin de faire de conversion et donc moins de travail est effectué, ce qui le rend plus rapide.


Je pense que votre opinion est contraire à ce que dit le manuel PHP. Ils disent que $ a == $ b est VRAI si $ a est égal à $ b, où $ a === $ b est VRAI si $ a est égal à $ b, et ils sont du même type.
Bakhtiyor

92
En quoi est-ce contraire alors?
meder omuraliev

2
Je crois que c'est en fait que les 2 opérandes pointent vers la même zone de mémoire pour les types complexes, mais la réponse de Meder englobe cela
Basique

1
Cela a du sens (comme dans JS), mais ce serait bien si quelqu'un ajoute également une référence à de vrais tests de performances simples.
Marco Demaio

4
phpbench.com a une indication de la différence de performance entre == et === dans la section "Structures de contrôle".
ekillaby

54

===n'effectue pas de transtypage, donc 0 == '0'évalue vers true, mais 0 === '0'- vers false.


25

Tout d'abord, === vérifie si les deux arguments sont du même type - donc le nombre 1 et la chaîne «1» échouent lors de la vérification de type avant que toute comparaison ne soit réellement effectuée. D'un autre côté, == ne vérifie pas le type d'abord et continue et convertit les deux arguments dans le même type, puis effectue la comparaison.

Par conséquent, === est plus rapide pour vérifier une condition d'échec


8
Je suppose que cela ==vérifie également le type en premier pour voir si une conversion de type doit être effectuée. Le fait que ===cela n'effectue aucune conversion à l'étape suivante est ce qui le rend plus rapide.
deceze

25

Il y a deux choses à considérer:

  1. Si les types d'opérande sont différents alors ==et ===produisent des résultats différents . Dans ce cas, la vitesse des opérateurs n'a pas d'importance; ce qui compte, c'est celui qui produit le résultat souhaité.

  2. Si les types d'opérande sont identiques, vous pouvez utiliser l'un ==ou l' autre ou ===les deux produiront les mêmes résultats . Dans ce cas, la vitesse des deux opérateurs est presque identique. En effet, aucune conversion de type n'est effectuée par l'un ou l'autre des opérateurs.

J'ai comparé la vitesse de:

  • $a == $b contre $a === $b
  • $aet $bétaient des entiers aléatoires [1, 100]
  • les deux variables ont été générées et comparées un million de fois
  • les tests ont été exécutés 10 fois

Et voici les résultats:

 $a == $b $a === $b
--------- ---------
 0.765770  0.762020
 0.753041  0.825965
 0.770631  0.783696
 0.787824  0.781129
 0.757506  0.796142
 0.773537  0.796734
 0.768171  0.767894
 0.747850  0.777244
 0.836462  0.826406
 0.759361  0.773971
--------- ---------
 0.772015  0.789120

Vous pouvez voir que la vitesse est presque identique.


13
Je me demande ce qui se passe si vous faites quelques milliards d'itérations sur une machine qui ne fait rien d'autre et que vous sortez simplement la moyenne. on dirait qu'il y a pas mal de bruit ici. ;)
Gung Foo

4
Je suis arrivé à la même conclusion: aucune différence ne pourrait être signalée si les opérandes sont connus pour être du même type. D'autres scénarios n'ont aucun sens. Presque toutes les autres réponses sont tout simplement fausses.
Paul Spiegel

1
Je pense que cela aurait dû être la réponse choisie. Il ne se rationalise pas simplement avec des hypothèses, les hypothèses ont été plus ou moins testées empiriquement.
Pedro Amaral Couto

@PedroAmaralCouto Je ne pense pas, puisque 10 n'est pas une étude empirique. La raison principale pour laquelle il n'y a pratiquement aucune différence est que le compilateur PHP optimisera probablement le code. On devrait utiliser === sauf si une conversion de type est nécessaire, cela aidera à réduire l'erreur sémantique (même si c'est une fois dans votre vie). Cela aide également la prochaine personne à lire le code quelles règles sont appliquées. Vous écrivez une fois, c'est lu quelques centaines de fois, si cela peut aider à dissiper le doute d'une personne, c'est déjà réussi. Aussi pas de test de mémoire si Empirique, puisque cloné au même type. Il y a plus de ressources que de temps.
Marco

@Marco, quand je dis «étude empirique», je veux dire qu'elle est basée sur l'expérience, par exemple: exécuter du code au lieu de faire un argument en utilisant uniquement la raison (ou ce que vous pensez), sans expérience pour le sauvegarder. Les valeurs de Salman A suggèrent que === est également parfois un peu plus rapide et parfois un peu plus lent. Cela signifie le "Pourquoi === est-il plus rapide que == en PHP?" pose la question: "Comment savez-vous que === est plus rapide que =="? Les optimisations du compilateur sont une explication, pas ce qui est plus rapide ou plus lent et je n'ai pas dit ce qui devrait être utilisé.
Pedro Amaral Couto

7

Je ne sais pas vraiment si c'est beaucoup plus rapide, mais === dans la plupart des langues est une comparaison directe de type, tandis que == essaiera de faire de la coercition de type si nécessaire / possible pour obtenir une correspondance.


9
Javascript a l'opérateur ===.
Frank Shearar

Je suis sûr que vous pouvez faire === en lisp et schéma communs.
pupeno

Javascript - pas dans les définitions de 3 langues que j'ai vérifiées;) Et Lisp et Scheme sont beaucoup de choses, mais peu communes;)
TomTom

1
ruby a ===. Il m’a fallu trop longtemps pour me souvenir si cela faisait la même chose.
KitsuneYMG

1
Aussi, liveocs.adobe.com/flash/9.0/ActionScriptLangRefV3/… pour actionscript. Fondamentalement, google "égalité stricte".
Chris

4

Le == entraîne une surcharge de conversion de type plus importante avant la comparaison. === vérifie d'abord le type, puis continue sans avoir à faire de conversion de type.



3

En conclusion === est plus rapide car ne convertit pas le type de données pour voir si deux variables ont la même valeur, mais lorsque vous avez besoin de voir si deux variables ont la même valeur, vous utiliserez == si ne correspond pas à quel type sont des variables , ou === si est important aussi le type de variables.


0

Plus rapide ne doit pas être mesuré uniquement en temps d'exécution directe (les tests de performance directs sont presque négligeables dans ce cas). Cela dit, j'aurais besoin de voir un test impliquant une itération, ou récursivité, pour vraiment voir s'il existe une différence cumulative significative (lorsqu'elle est utilisée dans un contexte réaliste). Le temps de test et de débogage que vous économiserez lors de la gestion des cas extrêmes devrait également être significatif pour vous


0

En php (code c), la valeur est une "classe" comme:

class value
{
    $int_;
    $float_;
    $string_;
    $array_;
    $object_;
}

Lorsque vous êtes comparaient $a == $bet $aest le inttype, il y aura quelque chose comme:

if ($a->int_ == $b->int_ || $a->int_ == (int) $b->float_ || $a->int_ == (int) $b->string_ || ...)

mais string '1'ne sera pas converti en code ascii 49, il sera1 .

Lorsque vous comparez $a === $bet $aest le inttype, il y aura someting comme:

if ($a->int_ == $b->int_)

-4

Si les résultats du test sont corrects, il doit s'agir d'un problème de compilation,

Le processeur fera tout ce qu'on lui dit de faire sur un cycle d'horloge

S'il a moins à faire, ce sera plus rapide à faire

Une addition:

Ah bon en fait si le compilateur a déjà créé des charges de code machine à traiter, alors s'il a déjà ajouté des millions de trucs pour faire face au type de données à comparer, alors la suppression d'un IF "mineur" ne changera pas beaucoup la vitesse du tout.

Si quelqu'un lit encore ceci, alors je suis intéressé par plus de discussion.

Phil


N'avez-vous qu'une seule instruction IF dans votre base de code? C'est bizarre parce que dans chaque base de code sur laquelle j'ai travaillé, nous avons des milliers d'instructions IF ou comparatives appelées partout.
Lev
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.