Почему === быстрее чем == в PHP? - PullRequest
162 голосов

Ответы [ 10 ]

192 голосов
/ 08 марта 2010

Поскольку оператор равенства == временно или принудительно преобразует тип данных, чтобы увидеть, равен ли он другому операнду, в то время как === (оператор идентификации) не нуждается ни в каком преобразовании, и, следовательно, выполняется меньше работы , делая это быстрее.

53 голосов
/ 08 марта 2010

=== не выполняет типизацию, поэтому 0 == '0' оценивается как true, но 0 === '0' - до false.

24 голосов
/ 08 марта 2010

Во-первых, === проверяет, являются ли два аргумента одинаковыми type - поэтому число 1 и строка '1' завершаются неудачно при проверке типа до того, как какое-либо сравнение действительно будет выполнено.С другой стороны, == сначала не проверяет тип, а затем преобразует оба аргумента в один и тот же тип, а затем выполняет сравнение.

Следовательно, === быстрее проверяет условие сбоя

22 голосов
/ 25 января 2013

Есть две вещи, которые следует учитывать:

  1. Если типы операндов отличаются, то == и === дают разные результаты . В этом случае скорость операторов не имеет значения; важно то, какой из них дает желаемый результат.

  2. Если типы операндов одинаковы, вы можете использовать либо ==, либо ===, так как оба будут давать одинаковые результаты . В этом случае скорость обоих операторов практически одинакова. Это связано с тем, что ни один из операторов не выполняет преобразование типов.

Я сравнил скорость:

  • $a == $b против $a === $b
  • , где $a и $b были случайными целыми числами [1, 100]
  • две переменные были сгенерированы и сравнены миллион раз
  • тесты были проведены 10 раз

А вот и результаты:

 $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

Вы видите, что скорость почти идентична.

7 голосов
/ 08 марта 2010

На самом деле я не знаю, значительно ли это быстрее, но === в большинстве языков - это прямое сравнение типов, в то время как == попытается выполнить приведение типов, если это необходимо / возможно, чтобы получить совпадение.

4 голосов
/ 08 марта 2010

== влечет за собой большие издержки при преобразовании типов перед сравнением. === сначала проверяет тип, а затем продолжает работу без преобразования типов.

4 голосов
/ 08 марта 2010

Поскольку === не нужно приводить операнды к одному и тому же типу перед их сравнением.

Я сомневаюсь, что разница в скорости очень большая, хотя. При нормальных обстоятельствах вы должны использовать тот оператор, который имеет больше смысла.

2 голосов
/ 09 марта 2010

В заключение === быстрее, потому что не преобразует тип данных, чтобы увидеть, если две переменные имеют одинаковое значение, но когда вам нужно увидеть, если две переменные имеют одинаковое значение, вы будете использовать ==, если не важно, что тип - это переменные, или ===, если важен также тип переменных.

0 голосов
/ 17 августа 2018

Быстрее следует измерять не только во время непосредственного выполнения (в этом случае прямые тесты производительности практически ничтожны). Тем не менее, мне нужно было бы увидеть тест, включающий итерацию или рекурсию, чтобы действительно увидеть, есть ли существенная, накопленная разница (при использовании в реалистическом контексте). Время тестирования и отладки, которое вы сэкономите при работе с крайними случаями, должно быть значимым для вас, также

0 голосов
/ 08 декабря 2015

Если результаты теста верны, то это должно быть проблемой компилятора,

Процессор будет делать все, что ему говорят, в тактовом цикле

Если будет меньше, то будет быстрее

Дополнительно:

Ну, на самом деле, если компилятор уже создал множество машинного кода для обработки, то если он уже добавил миллиарды вещей, чтобы справиться с тем, какой тип данных требует сравнения, то удаление одного "второстепенного" IF не будет изменить скорость сильно на всех.

Если кто-то все еще читает это, тогда я заинтересован в дальнейшем обсуждении.

Phil

...