Dlaczego === szybciej niż == w PHP?

Dlaczego jest ===szybszy niż ==w PHP?

Ponieważ operator równości ==wymusza lub konwertuje typ danych tymczasowo, aby sprawdzić, czy jest równy innemu operandowi, podczas gdy ===(operator tożsamości) nie musi wykonywać żadnej konwersji, a zatem wykonuje się mniej pracy, co czyni go szybszym.

===nie wykonuje rzutowania, więc 0 == '0'oblicza do true, ale 0 === '0'- do false.

Po pierwsze, === sprawdza, czy dwa argumenty są tego samego typu - więc liczba 1 i ciąg „1” nie sprawdzają typu, zanim jakiekolwiek porównania zostaną faktycznie przeprowadzone. Z drugiej strony == nie sprawdza najpierw typu i przechodzi dalej i konwertuje oba argumenty na ten sam typ, a następnie wykonuje porównanie.

Dlatego === szybciej sprawdza warunek niepowodzenia

Należy wziąć pod uwagę dwie kwestie:

1. Jeśli są różne typy argumentów operacji wtedy ==i ===produkować różne wyniki . W takim przypadku prędkość operatorów nie ma znaczenia; liczy się, który z nich daje pożądany rezultat.

2. Jeśli typy operandów są takie same, możesz użyć jednego ==lub ===obu, ponieważ dadzą te same wyniki . W takim przypadku prędkość obu operatorów jest prawie identyczna. Dzieje się tak, ponieważ żaden z operatorów nie przeprowadza konwersji typu.

Porównałem prędkość:

• $a == $b vs $a === $b
• gdzie $ai $bbyły losowymi liczbami całkowitymi [1, 100]
• dwie zmienne zostały wygenerowane i porównane milion razy
• testy przeprowadzono 10 razy

A oto wyniki:

 $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

Widać, że prędkość jest prawie identyczna.

Naprawdę nie wiem, czy jest to znacznie szybsze, ale === w większości języków jest bezpośrednim porównaniem typów, podczas gdy == spróbuje użyć przymusu typu, jeśli to konieczne / możliwe, aby uzyskać dopasowanie.

== powoduje większy koszt konwersji typu przed porównaniem. === najpierw sprawdza typ, a następnie kontynuuje bez konieczności wykonywania jakiejkolwiek konwersji typu.

Ponieważ === nie trzeba zmuszać operandów, aby były tego samego typu przed ich porównaniem.

Wątpię jednak, żeby różnica w prędkości była bardzo duża. W normalnych okolicznościach należy użyć dowolnego operatora, który ma większy sens.

Podsumowując, === jest szybsze, ponieważ nie konwertuje typu danych, aby zobaczyć, czy dwie zmienne mają tę samą wartość, ale kiedy chcesz sprawdzić, czy dwie zmienne mają tę samą wartość, użyjesz == jeśli nie ma znaczenia, jakiego typu są zmienne lub === jeśli ważny jest również typ zmiennych.

Szybsze nie powinno być mierzone tylko w bezpośrednim czasie wykonania (bezpośrednie testy wydajności są w tym przypadku prawie pomijalne). To powiedziawszy, musiałbym zobaczyć test obejmujący iterację lub rekurencję, aby naprawdę zobaczyć, czy istnieje znacząca, skumulowana różnica (w przypadku użycia w realistycznym kontekście). Znaczący powinien być również czas testowania i debugowania, który zaoszczędzisz podczas zajmowania się skrajnymi przypadkami

W php (kod c) wartością jest „klasa”, na przykład:

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

Kiedy Twój porównujesz $a == $bi $ajest inttypu, nie będzie coś takiego:

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

ale string '1'nie będzie rzutowany na kod ascii 49, będzie 1.

Kiedy porównujesz $a === $bi $ajest inttypu, nie będzie cos takiego jak:

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

Jeśli wyniki testu są prawidłowe, to musi to być problem kompilatora,

Procesor zrobi wszystko, co mu każą w cyklu zegara

Jeśli ma mniej do zrobienia, będzie to szybsze

Dodanie:

No cóż, właściwie, jeśli kompilator utworzył już mnóstwo kodu maszynowego do przetworzenia, to jeśli dodał już miliardy rzeczy, aby poradzić sobie z typem danych, które wymagają porównania, to usunięcie jednego "pomniejszego" IF nie zmieni znacznie prędkości w ogóle.

Jeśli ktoś jeszcze to czyta, jestem zainteresowany dalszą dyskusją.

Phil