Por que === é mais rápido que == no PHP?


168

Por que é ===mais rápido que ==no PHP?


40
É mais rápido, mas é significativamente mais rápido?
Piskvor saiu do prédio em 08/03/10

19
Por favor, não leia sobre o que é mais rápido no php. Leia sobre como obter dados interessantes em uma única consulta SQL sem abusar de JOINs.
Kamil Szot

15
Para quem possa estar interessado no mesmo assunto === vs ==, mas no JAVASCRIPT, pode ler aqui: stackoverflow.com/questions/359494/…
Marco Demaio 31/12/10

5
@Piskvor, essa não é a questão
Pacerier

6
@ Pacerier: Fair point - é por isso que apenas comentei isso. Não responde à pergunta, mas fornece perspectiva sobre ela.
Piskvor saiu do prédio

Respostas:


200

Como o operador de igualdade ==coage ou converte, o tipo de dados temporariamente para ver se é igual ao outro operando, enquanto ===(o operador de identidade) não precisa fazer nenhuma conversão e, portanto, menos trabalho é feito, o que o torna mais rápido.


Eu acho que sua opinião é contrária ao que o Manual do PHP diz. Eles dizem que $ a == $ b é VERDADEIRO se $ a for igual a $ b, onde $ a === $ b é VERDADEIRO se $ a for igual a $ b e eles são do mesmo tipo.
Bakhtiyor

92
Como isso é contrário, então?
meder omuraliev

2
Eu acredito que, na verdade, os 2 operandos apontam para a mesma área de memória para tipos complexos, mas a resposta do médico abrange isso
Basic

1
Faz sentido (como em JS), mas seria bom se alguém adicionasse também uma referência a alguns testes de desempenho simples e reais.
Marco Demaio

4
O phpbench.com tem uma indicação da diferença de desempenho entre == e === na seção "Estruturas de controle".
ekillaby

54

===não executa a conversão de tipo, então 0 == '0'avalia para true, mas 0 === '0'- para false.


25

Primeiro, === verifica se os dois argumentos são do mesmo tipo - portanto, o número 1 e a string '1' falham na verificação de tipo antes que quaisquer comparações sejam realmente realizadas. Por outro lado, == não verifica o tipo primeiro e segue em frente e converte os dois argumentos no mesmo tipo e depois faz a comparação.

Portanto, === é mais rápido na verificação de uma condição de falha


8
Eu acho que isso ==também verifica primeiro o tipo para ver se é necessário fazer alguma conversão de tipo. O fato de ===não fazer nenhuma conversão na etapa a seguir é o que a torna mais rápida.
deceze

25

Há duas coisas a considerar:

  1. Se tipos de operando é diferente ==e ===produzir resultados diferentes . Nesse caso, a velocidade dos operadores não importa; o que importa é qual produz o resultado desejado.

  2. Se os tipos de operando forem iguais, você poderá usar um ==ou ===ambos, pois ambos produzirão os mesmos resultados . Nesse caso, a velocidade dos dois operadores é quase idêntica. Isso ocorre porque nenhuma conversão de tipo é realizada por nenhum dos operadores.

Eu comparei a velocidade de:

  • $a == $b vs $a === $b
  • onde $ae $bforam números inteiros aleatórios [1, 100]
  • as duas variáveis ​​foram geradas e comparadas um milhão de vezes
  • os testes foram executados 10 vezes

E aqui estão os 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

Você pode ver que a velocidade é quase idêntica.


13
Gostaria de saber o que acontece se você fizer alguns bilhões de iterações em uma máquina que não está fazendo mais nada e apenas gerar a média. Parece que há muito barulho aqui. ;)
Gung Foo 12/02

4
Cheguei à mesma conclusão: nenhuma diferença poderia ser alterada se os operandos fossem do mesmo tipo. Outros cenários não fazem sentido. Quase todas as outras respostas estão erradas.
Paul Spiegel

1
Acredito que essa deveria ter sido a resposta selecionada. Ele não apenas racionaliza com suposições, as suposições foram mais ou menos testadas empiricamente.
Pedro Amaral Couto

@PedroAmaralCouto Acho que não, pois 10 não é um estudo empírico. A principal razão pela qual não há quase nenhuma diferença é que o compilador PHP provavelmente otimizará o código. Deve-se usar ===, a menos que seja necessária a conversão de tipos, isso ajudará a reduzir o erro semântico (mesmo que seja uma vez na vida inteira). Também ajuda a próxima pessoa a ler o código de quais regras são aplicadas. Você escreve uma vez, é lido centenas de vezes; se ajudar a esclarecer a dúvida de uma pessoa, já foi bem-sucedido. Também não há teste de memória empírico, pois clone para o mesmo tipo. Existem mais recursos do que apenas tempo.
20919 Marco Marco

@Marco, quando digo "estudo empírico", quero dizer que é baseado na experiência, por exemplo: executar código em vez de argumentar usando apenas a razão (ou o que está em sua mente), sem um experimento para fazer o backup. Os valores de Salman A sugerem === às vezes é um pouco mais rápido e às vezes um pouco mais lento. Isso significa que "Por que é === mais rápido que == no PHP?" implora a pergunta: "Como você sabe que === é mais rápido que =="? As otimizações do compilador são uma explicação, não o que é mais rápido ou mais lento, e eu não disse o que deveria ser usado.
Pedro Amaral Couto

7

Eu realmente não sei se é significativamente mais rápido, mas === na maioria dos idiomas é uma comparação direta de tipos, enquanto == tentará fazer coerção de tipo, se necessário / possível para obter uma correspondência.


9
Javascript tem o operador ===.
precisa saber é o seguinte

Tenho certeza que você pode fazer === em comum lisp e esquema.
pupeno

Javascript - não em 3 definições langauge eu verifiquei;) E Lisp e Scheme muitas coisas, mas dificilmente comum;)
TomTom

1
ruby tem ===. Faz muito tempo para eu lembrar se faz a mesma coisa.
precisa saber é o seguinte

1
Além disso, livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/… para actionscript. Basicamente, o Google "igualdade estrita".
31510 Chris

4

O == incorre em uma sobrecarga maior de conversão de tipo antes da comparação. === primeiro verifica o tipo e depois continua sem precisar fazer nenhuma conversão de tipo.



3

Em conclusão, === é mais rápido, porque não converte o tipo de dados para ver se duas variáveis ​​têm o mesmo valor, mas quando você precisar ver se duas variáveis ​​têm o mesmo valor, você usará == se não for mais matemático, que tipo são variáveis ou === se for importante também o tipo de variáveis.


0

Mais rápido não deve ser medido apenas no tempo de execução direta (neste caso, os testes de desempenho direto são quase insignificantes). Dito isso, eu precisaria ver um teste envolvendo iteração ou recursão para realmente ver se há uma diferença cumulativa significativa (quando usada em um contexto realista). O tempo de teste e depuração que você economizará ao lidar com casos extremos deve ser significativo para você, também


0

No php (código c), o valor é uma "classe" como:

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

Quando você está comparando $a == $be $aé do inttipo, haverá algo como:

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

mas string '1'não será convertido para código ascii 49, será 1.

Quando você está comparando $a === $be $aé do inttipo, haverá algo como:

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

-4

Se os resultados do teste estiverem corretos, será um problema do compilador,

O processador fará o que for solicitado para fazer em um ciclo de clock

Se tiver menos a fazer, será mais rápido fazer

Adição:

Ah, na verdade, se o compilador já criou um monte de código de máquina a ser processado, se já adicionou milhões de itens para lidar com que tipo de dados precisa ser comparado, a remoção de um "menor" SE não mudará muito a velocidade em absoluto.

Se alguém ainda lê isso, então eu sou interessante em mais discussões.

Phil


Você tem apenas "uma" instrução IF em sua base de código? Isso é estranho, porque em toda base de código em que trabalhei, temos milhares de declarações IF ou comparativas chamadas por toda parte.
Lev
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.