Pourquoi est - = = = plus rapide que l' == en PHP?

Pourquoi est === plus vite que == en PHP?

  • Il est plus rapide, mais il est nettement plus rapide?
  • S'il vous plaît ne pas lire à propos de ce qui est plus rapide en php. Lisez à propos de la façon d'obtenir des données intéressantes dans une seule requête SQL sans abuser de Jointures.
  • À qui pourraient être intéressés par le même sujet === vs ==, mais en JAVASCRIPT, peut lire ici: stackoverflow.com/questions/359494/...
  • ce n'est pas la question
  • Juste point - c'est pourquoi je ne l'ai commenté sur ce. Il ne répond pas à la question, mais donne une perspective sur elle.
InformationsquelleAutor coderex | 2010-03-08
  1. 191

    Parce que l'opérateur d'égalité == contraint, ou convertit le type de données temporairement pour voir si elle est égale à l'autre opérande alors que === ( identité opérateur ) n'a pas besoin de faire une conversion que ce soit et donc de moins en moins le travail est fait, le rendant plus rapide.

    • Je pense que votre opinion est contraire à ce que le Manuel PHP dit. Ils disent que $a == $b est VRAI si $a est égal à $b, $a === $b est VRAI si $a est égal à $b, et qu'ils sont de même type.
    • Comment est-il contraire, alors?
    • Je crois que c'est en fait que les 2 opérandes point à la même zone de mémoire pour les types complexes mais meder la réponse de celui
    • Elle a un sens (comme c'est en JS), mais ce serait sympa si quelqu'un ajoute également une référence à des choses toutes simples tests de performance.
    • phpbench.com a une indication de la différence de performances entre == et === sous les "Structures de Contrôle" de la section.
    InformationsquelleAutor meder omuraliev
  2. 53

    === ne pas effectuer typecasting, donc 0 == '0' évalue à true, mais 0 === '0' - à false.

    InformationsquelleAutor raveren
  3. 24

    D'abord, === vérifie si les deux arguments sont les mêmes type - de sorte que le nombre 1 et la chaîne de caractères '1' échoue sur la vérification de type avant toute comparaison de la réalité. D'autre part, == ne vérifie pas le type de premier et va de l'avant et convertit les deux arguments du même type et fait ensuite la comparaison.

    Par conséquent, === est plus rapide à la vérification de l'échec de la condition

    • Je suppose que == vérifie également le type d'abord pour voir si n'importe quel type de conversion doit être fait. Le fait que === ne fait pas de conversion dans l'étape suivante est ce qui le rend plus rapide.
    InformationsquelleAutor iblamefish
  4. 21

    Il y a deux choses à considérer:

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

    2. Si l'opérande types de sont même, alors vous pouvez utiliser == ou === que les deux vont produire mêmes résultats. Dans ce cas, la vitesse de ces deux opérateurs est presque identique. C'est parce qu'aucune conversion de type est effectuée par les opérateurs.

    J'ai comparé la vitesse de:

    • $a == $b vs $a === $b
    • où $a et $b étaient aléatoires entiers [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.

    • je me demande ce qui se passe si vous faites quelques milliards d'itérations sur une machine qui n'est pas à faire autre chose et juste à la sortie de la moyenne. regarde comme il y a assez beaucoup de bruit ici. 😉
    • Je suis venu à la même conclusion: Aucune différence n'a pu être mesuré si les opérandes sont connus pour être de même type. D'autres scénarios ne font pas sens. Presque toutes les autres réponses sont tout simplement faux.
    • Je crois que cela aurait dû être la réponse choisie. Il ne se contente pas de rationaliser avec des hypothèses, des hypothèses ont été plus ou moins testé empiriquement.
    InformationsquelleAutor Salman A
  5. 7

    Je ne sais pas vraiment si c'est nettement plus rapide, mais === dans la plupart des langues est une conséquence directe de type de comparaison, alors que == va essayer de faire de ce type de coercition si nécessaire/possible pour gagner un match.

    • Javascript a l' === opérateur.
    • Je suis sûr que vous pouvez le faire === en common lisp et scheme.
    • Javascript - pas dans les 3 langues les définitions que j'ai vérifié 😉 Et Lisp et Scheme beaucoup de choses, mais peu commun 😉
    • ruby a ===. Il a été trop longtemps pour me souvenir si il fait la même chose.
    • Aussi, livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/... pour actionscript. En gros, google "égalité stricte".
    InformationsquelleAutor Chris
  6. 4

    L' == subit des plus grands généraux de la conversion de type avant comparaison. === vérifie d'abord le type, puis le produit sans avoir à faire n'importe quel type de conversion.

    InformationsquelleAutor Martin
  7. 4

    Parce que === n'a pas besoin de forcer les opérandes de même type avant de les comparer.

    Je doute que la différence de vitesse est très très bien. Dans des circonstances normales, vous devez utiliser n'importe quel opérateur plus de sens.

    InformationsquelleAutor John Carter
  8. 2

    En conclusion === est plus rapide car ne convertit le type de données pour voir si les deux variables ont la même valeur, mais quand vous avez besoin de voir si deux variables ont la même valeur, vous allez utiliser == si doesen " mather ce type sont variables, ou === si est important de également le type de variables.

    InformationsquelleAutor D.Martin
  9. 0

    Plus rapide ne doit pas seulement être mesurée en direct temps d'exécution (direct les tests de performances sont presque négligeable dans ce cas). Cela dit, j'aurais besoin de voir un test de l'itération ou la récursivité, pour vraiment voir si il y a une importante différence cumulative (lorsqu'il est utilisé dans un contexte réaliste). Le test et le débogage de temps que vous gagnerez lorsque vous traitez avec des cas limites doivent avoir du sens pour vous, aussi

    InformationsquelleAutor Anthony Rutledge
  10. -3

    Si les résultats des tests sont corrects, alors il doit être un compilateur problème,

    Le processeur va faire tout ce qu'il est dit de le faire sur un cycle d'horloge

    Si elle a moins de le faire alors il sera plus rapide de le faire

    Plus:

    Ah bon, en fait, si le compilateur a déjà créé des charges de la machine de traitement du code, puis si on a déjà ajouté des milliards de trucs à faire face à ce type de données, les besoins de la comparaison, alors que la suppression d'un "mineur" SI pas de changement de vitesses beaucoup à tous.

    Si quelqu'un lit encore ce sont ensuite je suis intéressé par de plus amples discussions.

    Phil

    InformationsquelleAutor Phil Allen