¿Por qué es === más rápido que == en PHP?


168

¿Por qué es ===más rápido que ==en PHP?


40
Es más rápido, pero ¿es significativamente más rápido?
Piskvor salió del edificio el

19
Por favor, no lea sobre lo que es más rápido en php. Lea sobre cómo obtener datos interesantes en una sola consulta SQL sin abusar de JOIN.
Kamil Szot

15
Para quienes puedan estar interesados ​​en el mismo tema === vs ==, pero en JAVASCRIPT, puede leer aquí: stackoverflow.com/questions/359494/…
Marco Demaio

55
@Piskvor, esa no es la pregunta
Pacerier

66
@Pacerier: Punto justo, es por eso que solo he comentado sobre esto. No responde la pregunta, pero proporciona una perspectiva al respecto.
Piskvor salió del edificio

Respuestas:


200

Debido a que el operador de igualdad ==coacciona o convierte, el tipo de datos temporalmente para ver si es igual al otro operando, mientras que ===(el operador de identidad) no necesita hacer ninguna conversión y, por lo tanto, se realiza menos trabajo, lo que lo hace más rápido.


Creo que su opinión es contraria a lo que dice el Manual PHP. Dicen que $ a == $ b es VERDADERO si $ a es igual a $ b, donde $ a === $ b es VERDADERO si $ a es igual a $ b, y son del mismo tipo.
Bakhtiyor

92
¿Cómo es contrario, entonces?
meder omuraliev

2
Creo que en realidad es que los 2 operandos apuntan a la misma área de memoria para los tipos complejos, pero la respuesta de Meder abarca eso
Básico

1
Tiene sentido (como lo es en JS), pero sería bueno si alguien agrega también una referencia a algunas pruebas de rendimiento realmente simples.
Marco Demaio

44
phpbench.com tiene una indicación de la diferencia de rendimiento entre == y === en la sección "Estructuras de control".
ekillaby

54

===no realiza la conversión de texto, por lo que 0 == '0'evalúa a true, pero 0 === '0'- a false.


25

Primero, === verifica si los dos argumentos son del mismo tipo , por lo que el número 1 y la cadena '1' fallan en la verificación de tipo antes de que se realicen las comparaciones. Por otro lado, == no comprueba el tipo primero y sigue adelante y convierte ambos argumentos al mismo tipo y luego hace la comparación.

Por lo tanto, === es más rápido al verificar una condición de falla


8
Supongo que eso ==también verifica primero el tipo para ver si es necesario realizar alguna conversión de tipo. El hecho de que ===no realice ninguna conversión en el siguiente paso es lo que lo hace más rápido.
deceze

25

Hay dos cosas a considerar:

  1. Si los tipos de operandos son diferentes, ==y ===producen resultados diferentes . En ese caso, la velocidad de los operadores no importa; lo que importa es cuál produce el resultado deseado.

  2. Si los tipos de operandos son los mismos, puede usar uno ==o ===ambos producirán los mismos resultados . En ese caso, la velocidad de ambos operadores es casi idéntica. Esto se debe a que ninguno de los operadores realiza conversión de tipo.

Comparé la velocidad de:

  • $a == $b vs $a === $b
  • donde $ay $beran enteros aleatorios [1, 100]
  • las dos variables fueron generadas y comparadas un millón de veces
  • las pruebas se realizaron 10 veces

Y aquí están los resultados:

 $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

Puedes ver que la velocidad es casi idéntica.


13
Me pregunto qué pasará si haces miles de millones de iteraciones en una máquina que no está haciendo nada más y solo genera el promedio. Parece que hay mucho ruido aquí. ;)
Gung Foo

44
Llegué a la misma conclusión: no se podría confundir la diferencia si se sabe que los operandos son del mismo tipo. Otros escenarios no tienen sentido. Casi todas las otras respuestas son simplemente incorrectas.
Paul Spiegel

1
Creo que esta debería haber sido la respuesta seleccionada. No solo se racionaliza con supuestos, los supuestos se probaron más o menos empíricamente.
Pedro Amaral Couto

@PedroAmaralCouto No lo creo, ya que 10 no es un estudio empírico. La razón principal por la que casi no hay diferencia es que el compilador de PHP probablemente optimizará el código. Uno debe usar === a menos que se necesite conversión de tipo, ayudará a reducir el error semántico (incluso si es una vez en toda su vida). También ayuda a la siguiente persona que lee el código qué reglas se aplican. Escribe una vez, se lee cientos de veces, si puede ayudar a aclarar la duda de una persona, ya ha tenido éxito. Tampoco hay prueba de memoria si es empírica, ya que clonar al mismo tipo. Hay más recursos que solo tiempo.
Marco

@Marco, cuando digo "estudio empírico", me refiero a que se basa en la experiencia, por ejemplo: ejecutar código en lugar de hacer un argumento utilizando solo la razón (o lo que está en su mente), sin un experimento que lo respalde. Los valores de Salman A sugieren que === es igualmente a veces un poco más rápido ya veces un poco más lento. Esto significa "¿Por qué es === más rápido que == en PHP?" plantea la pregunta: "¿Cómo sabes que === es más rápido que =="? Las optimizaciones del compilador es una explicación, no lo que es más rápido o más lento y no dije qué debería usarse.
Pedro Amaral Couto

7

Realmente no sé si es significativamente más rápido, pero === en la mayoría de los idiomas es una comparación de tipo directa, mientras que == intentará hacer una coerción de tipo si es necesario / posible para obtener una coincidencia.


9
Javascript tiene el operador ===.
Frank Shearar

Estoy seguro de que puedes hacer === en lisp y esquema comunes.
pupeno

Javascript: no en 3 definiciones de idioma que verifiqué;) Y Lisp y Scheme son muchas cosas, pero apenas comunes;)
TomTom

1
Ruby tiene ===. Ha sido demasiado tiempo para recordar si hace lo mismo.
KitsuneYMG

1
Además, livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/… para actionscript. Básicamente, google "igualdad estricta".
Chris

4

El == incurre en una mayor sobrecarga de conversión de tipo antes de la comparación. === primero verifica el tipo, luego continúa sin tener que hacer ninguna conversión de tipo.



3

En conclusión === es más rápido porque no convierte el tipo de datos para ver si dos variables tienen el mismo valor, pero cuando necesite ver si dos variables tienen el mismo valor, usará == si no importa qué tipo de variables son , o === si es importante también el tipo de variables.


0

Más rápido no solo debe medirse en tiempo de ejecución directo (las pruebas de rendimiento directo son casi insignificantes en este caso). Dicho esto, necesitaría ver una prueba que implique iteración o recursividad, para ver realmente si hay una diferencia significativa y acumulativa (cuando se usa en un contexto realista). El tiempo de prueba y depuración que ahorrará al tratar con casos límite también debe ser significativo para usted


0

En php (código c) el valor es una "clase" como:

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

Cuando su están comparando $a == $by $aes intel tipo, habrá algo así como:

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

pero string '1'no se lanzará al código ASCII 49, lo será 1.

Cuando esté comparando $a === $by $aes inttipo, habrá algo como:

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

-4

Si los resultados de la prueba son correctos, entonces debe ser un problema del compilador,

El procesador hará lo que se le indique en un ciclo de reloj.

Si tiene menos que hacer, será más rápido hacerlo

Adición:

Ah, bueno, en realidad, si el compilador ya ha creado un montón de código de máquina para procesar, si ya ha agregado millones de cosas para hacer frente a qué tipo de datos necesita comparar, entonces la eliminación de un IF "menor" no cambiará mucho las velocidades en absoluto.

Si alguien todavía lee esto, entonces estoy interesado en más discusión.

Phil


¿Solo tiene "una" instrucción IF en su código base? Eso es extraño porque en cada código base en el que he trabajado, tenemos miles de declaraciones IF o comparativas llamadas en todas partes.
Lev
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.