174

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

Rob W
  • 341,306
  • 83
  • 791
  • 678
coderex
  • 27,225
  • 45
  • 116
  • 170
  • 40
    It is faster, but is it *significantly* faster? – Piskvor left the building Mar 08 '10 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. – Kamil Szot Mar 10 '10 at 03:20
  • 15
    To whom it might be interested in the same subject `=== vs ==`, but in JAVASCRIPT, can read here: http://stackoverflow.com/questions/359494/javascript-vs-does-it-matter-which-equal-operator-i-use – Marco Demaio Dec 31 '10 at 12:35
  • 5
    @Piskvor, that's not the question – Pacerier Jul 05 '13 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. – Piskvor left the building Feb 19 '14 at 11:30
  • Absolutely, we should avoid petty optimizations if they waste time that we could be using to learn proper SQL, but having this in your back pocket as a best practice is worth the few seconds it takes to comprehend the question. Most of us are programmers because we love to understand the inner-workings of things like this! – pbarney Aug 18 '20 at 14:48

12 Answers12

210

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
  • 523
  • 2
  • 10
  • 20
meder omuraliev
  • 183,342
  • 71
  • 393
  • 434
  • 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. – Bakhtiyor Jun 17 '10 at 08:58
  • 2
    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 – Basic Aug 24 '10 at 19:21
  • 1
    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. – Marco Demaio Dec 31 '10 at 12:37
  • 5
    http://www.phpbench.com/ has an indication of performance difference between == and === under the "Control Structures" section. – awhie29urh2 Feb 26 '13 at 06:17
  • ok then would there be any difference using just `if(value)` rather than `if(value===true)` or `if(value==true)` ? – Muhammad Omer Aslam Jan 15 '20 at 23:39
  • @MuhammadOmerAslam in `if(value)` the `value` is *directly converted to Boolean* and then evaluated, while the strict comparison (`===`) instead *performs a comparison to obtain a Boolean* which is then evaluated. The comparison probably takes longer in most if not all cases. But any performance benefit there should be insignificant and our time better spent either on solving problems more efficiently or on just making the code more readable. – JPR Jan 16 '20 at 07:15
57

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

raveren
  • 17,799
  • 12
  • 70
  • 83
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.

Salman A
  • 262,204
  • 82
  • 430
  • 521
  • 15
    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. ;) – Gung Foo Feb 12 '13 at 23:28
  • 4
    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. – Paul Spiegel Dec 05 '17 at 15:58
  • 1
    I believe this should have been the selected answer. It doesn't merely rationalise with assumptions, the assumptions were more ore less tested empirically. – Pedro Amaral Couto Mar 31 '18 at 17:56
  • @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 Jul 20 '19 at 15:41
  • @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. – Pedro Amaral Couto Sep 02 '19 at 11:13
  • @PedroAmaralCouto the answer given is 10 examples, which doesn't rule out a lot of external factors nor does Salman show how the examples were produced. I'm still pretty sure that the compiler would optimize them all not to have type conversion if possible, e.g. a quick type comparison is done first with type in memory, if you upped it to way larger numbers (of comparisons not number itself) where previous result can't be stored in the CPU cache, what result would you get? Or if you used e.g. BigInt/objects, etc. where custom variable types might "trick" the compiler. – Marco Sep 09 '19 at 08:44
  • I actually found a significant difference: === being 15% faster than ==. see here https://stackoverflow.com/a/65126758/10126479 – 8ctopus Dec 03 '20 at 13:19
  • @8ctopus are you comparing two identical datatypes in those tests? – Salman A Dec 03 '20 at 13:26
  • @SalmanA no, the comparison is between a bool and an int so conversion needs to occur. – 8ctopus Dec 03 '20 at 13:36
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

clinton3141
  • 4,751
  • 3
  • 33
  • 46
  • 10
    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. – deceze Jul 26 '10 at 09:37
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.

Chris
  • 27,596
  • 25
  • 124
  • 225
5

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

Martin
  • 2,956
  • 7
  • 30
  • 59
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.

Community
  • 1
  • 1
John Carter
  • 53,924
  • 26
  • 111
  • 144
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.

D.Martin
  • 116
  • 1
2

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%
---------------------------------------------------
8ctopus
  • 2,617
  • 2
  • 18
  • 25
0

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

Anthony Rutledge
  • 6,980
  • 2
  • 39
  • 44
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_)
d0niek
  • 218
  • 1
  • 12
-3

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

Phil Allen
  • 153
  • 2
  • 7
  • 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. – SikoSoft Oct 04 '19 at 07:47