176

Why is === faster than == in PHP?

Rob W
350k87 gold badges811 silver badges683 bronze badges
asked Mar 8, 2010 at 13:14
7
  • 41
    It is faster, but is it significantly faster? Commented Mar 8, 2010 at 13:17
  • 21
    Please don't read about what's faster in php. Read about how to get interesting data in single SQL query without abusing JOINs. Commented Mar 10, 2010 at 3:20
  • 15
    To whom it might be interested in the same subject === vs ==, but in JAVASCRIPT, can read here: stackoverflow.com/questions/359494/… Commented Dec 31, 2010 at 12:35
  • 5
    @Piskvor, that's not the question Commented Jul 5, 2013 at 16:20
  • 6
    @Pacerier: Fair point - that's why I have only commented on this. It doesn't answer the question, but provides perspective on it. Commented Feb 19, 2014 at 11:30

12 Answers 12

209

Because the equality operator == coerces, or converts, the data type temporarily to see if it’s equal to the other operand, whereas === (the identity operator) doesn’t need to do any converting whatsoever and thus less work is done, which makes it faster.

Lucas
5412 gold badges10 silver badges23 bronze badges
answered Mar 8, 2010 at 13:16

6 Comments

I think your opinion is contrary with the what PHP Manual says. They say $a == $b is TRUE if $a is equal to $b, where $a === $b is TRUE if $a is equal to $b, and they are of the same type.
I believe it's actually that the 2 operands point to the same area of memory for complex types but meder's answer encompasses that
It makes sense (as it is in JS), but it would be nice if someone adds also a reference to some real simple performance tests.
phpbench.com has an indication of performance difference between == and === under the "Control Structures" section.
ok then would there be any difference using just if(value) rather than if(value===true) or if(value==true) ?
|
56

=== does not perform typecasting, so 0 == '0' evaluates to true, but 0 === '0' - to false.

answered Mar 8, 2010 at 13:17

Comments

27

There are two things to consider:

  1. If operand types are different then == and === produce different results. In that case the speed of the operators does not matter; what matters is which one produces the desired result.

  2. If operand types are same then you can use either == or === as both will produce same results. In that case the speed of both operators is almost identical. This is because no type conversion is performed by either operators.

I compared the speed of:

  • $a == $b vs $a === $b
  • where $a and $b were random integers [1, 100]
  • the two variables were generated and compared one million times
  • the tests were run 10 times

And here are the results:

 $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

You can see that the speed is almost identical.

answered Jan 25, 2013 at 11:35

9 Comments

i wonder what happens if you do some billion iterations on a machine that isn't doing anything else and just output the average. looks like there is pretty much noise in here. ;)
I came to the same conclusion: No difference could be messured if the operands are known to be from the same type. Other scenarios don't make sence. Almost all other answers are just wrong.
I believe this should have been the selected answer. It doesn't merely rationalise with assumptions, the assumptions were more ore less tested empirically.
@PedroAmaralCouto I don't think so, since 10 is not an empirical study. The main reason there is near no difference is that the PHP compiler will probably optimize the code. One should use === unless type conversion is needed, it will help to reduce semantic error (even if it's once in your entire life). It also helps the next person reading the code what rules are enforced. You write once, it's read a few hundred times, if it can help clear up one person's doubt, it's already succeeded. Also no memory test if Empirical, since clone to same type. There are more resources than only time.
@Marco, when I say "empirical study", I mean it's based on experience, eg: running code instead of making an argument using only reason (or what's in your mind), without an experiment to back it up. Salman A values suggest === is equally sometimes a bit faster and sometimes a bit slower. This means the "Why is === faster than == in PHP?" begs the question: "How do you know === is faster than =="? Compiler optimizations is an explanation, not what is faster or slower and I didn't say what should be used.
|
26

First, === checks to see if the two arguments are the same type - so the number 1 and the string '1' fails on the type check before any comparisons are actually carried out. On the other hand, == doesn't check the type first and goes ahead and converts both arguments to the same type and then does the comparison.

Therefore, === is quicker at checking a fail condition

answered Mar 8, 2010 at 13:16

1 Comment

I'd guess that == also checks the type first to see if any type conversion needs to be done. The fact that === doesn't do any conversion in the following step is what makes it faster.
7

I don't really know if it's significantly faster, but === in most languages is a direct type comparison, while == will try to do type coercion if necessary/possible to gain a match.

answered Mar 8, 2010 at 13:16

5 Comments

Javascript has the === operator.
I'm sure you can do === in common lisp and scheme.
Javascript - not in 3 langauge definitions I checked ;) And Lisp and Scheme are many things, but hardly common ;)
ruby has ===. It has been too long for me to remember if it does the same thing.
Also, livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/… for actionscript. Basically, google "strict equality".
5

The == incurs a larger overhead of type conversion before comparison. === first checks the type, then proceeds without having to do any type conversion.

answered Mar 8, 2010 at 13:18

Comments

4

Because === doesn't need to coerce the operands to be of the same type before comparing them.

I doubt the difference in speed is very much though. Under normal circumstances you should use whichever operator makes more sense.

answered Mar 8, 2010 at 13:17

Comments

3

In conclusion === is faster because don't converts the data type to see if two variables have same value, but when you need to see if two variables have same value you will use == if doesen't mather what type are variables, or === if is important also the type of variables.

answered Mar 9, 2010 at 20:03

Comments

3

I found out that there actually is a significant speed difference between the 2 operators. Results for php 8.0.0 RC5 and php 7.4.12 running in docker container below. The project is hosted on github so everyone can review the methodology. Disclaimer: I built the tool.

$ php src/benchmark.php --custom --filter ~equal~
PHP benchmark
-------------------------------
platform : Linux x64
php version : 7.4.12
xdebug : off
memory limit : 128M
max execution : 0
time per iteration : 50ms
iterations : 100
-------------------------------
---------------------------------------------------
0 : == ===
mean : 394156 459015 +16.5%
median : 397448 461822 +16.2%
mode : 398154 458062 +15.0%
minimum : 313271 405692 +29.5%
maximum : 411157 480360 +16.8%
quartile 1 : 393222 454952 +15.7%
quartile 3 : 400881 466491 +16.4%
IQ range : 7659 11538 +50.7%
std deviation : 15593 11867 -23.9%
normality : 0.8% 0.8%
---------------------------------------------------
$ php src/benchmark.php --custom --filter ~equal~
PHP benchmark
-------------------------------
platform : Linux x64
php version : 8.0.0RC5
xdebug : off
memory limit : 128M
max execution : 0
time per iteration : 50ms
iterations : 100
-------------------------------
---------------------------------------------------
0 : == ===
mean : 405032 474768 +17.2%
median : 409226 477313 +16.6%
mode : 408421 479741 +17.5%
minimum : 311606 386509 +24.0%
maximum : 417895 491842 +17.7%
quartile 1 : 405740 473436 +16.7%
quartile 3 : 412677 483139 +17.1%
IQ range : 6937 9703 +39.9%
std deviation : 17501 15657 -10.5%
normality : 1.0% 1.0%
---------------------------------------------------
answered Dec 3, 2020 at 13:17

Comments

0

In php (c code) value is a "class" like:

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

When your are comparing $a == $b and $a is int type, there will be something like:

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

but string '1' will not be cast to ascii code 49, it will be 1.

When you are comparing $a === $b and $a is int type, there will be someting like:

if ($a->int_ == $b->int_)
answered Feb 13, 2020 at 7:08

Comments

-1

Faster should not just be measured in direct execution time (direct performance tests are almost negligible in this case). That said, I would need to see a test involving iteration, or recursion, to really see if there is a significant, cumulative difference (when used in a realistic context). The testing and debugging time you will save when dealing with edge cases should be meaningful to you, also

answered Aug 17, 2018 at 15:20

Comments

-4

If the test results are correct, then it must be a compiler issue,

The processor will do whatever it is told to do on a clock cycle

If it has less to do then it will be quicker to do

Addition:

Ah well actually if the compiler has already created loads of machine code to be processed, then if it has already added zillions of stuff to cope with what type of data needs comparing, then the removal of one "minor" IF will not change speeds much at all.

If anyone still reads this are then I am interesting in more discussion.

Phil

answered Dec 7, 2015 at 21:54

1 Comment

Do you only have "one" IF statement in your code base? That's weird because in every code base I've worked on, we have thousands of IF or comparative statements called everywhere.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.