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

Question

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

Seger

It is faster, but is it significantly faster? – Repent

Please don't read about what's faster in php. Read about how to get interesting data in single SQL query without abusing JOINs. – Histaminase

To whom it might be interested in the same subject === vs ==, but in JAVASCRIPT, can read here: #359994 – Brachypterous

@Piskvor, that's not the question – Kalidasa

@Pacerier: Fair point - that's why I have only commented on this. It doesn't answer the question, but provides perspective on it. – Repent

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! – Khanate

@Khanate I agree, the difference is truly insignificant. See: 3v4l.org/RiEOg – Intramundane

Answer 1

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.

Timehonored

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. – Bodiless

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 – Ictus

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. – Brachypterous

phpbench.com has an indication of performance difference between == and === under the "Control Structures" section. – Chieftain

ok then would there be any difference using just if(value) rather than if(value===true) or if(value==true) ? – Intoxication

@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. – Fumble

Answer 2

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

Kernel

Answer 3

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.

Eastereasterday

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. ;) – Shell

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. – Philippopolis

I believe this should have been the selected answer. It doesn't merely rationalise with assumptions, the assumptions were more ore less tested empirically. – Holocene

@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. – Columbarium

@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. – Holocene

@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. – Columbarium

I actually found a significant difference: === being 15% faster than ==. see here https://mcmap.net/q/142486/-why-is-faster-than-in-php – Wilen

@Wilen are you comparing two identical datatypes in those tests? – Eastereasterday

@SalmanA no, the comparison is between a bool and an int so conversion needs to occur. – Wilen

Answer 4

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

Sharleensharlene

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. – Ploch

Answer 5

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.

Falsecard

Javascript has the === operator. – Midinette

I'm sure you can do === in common lisp and scheme. – Vella

Javascript - not in 3 langauge definitions I checked ;) And Lisp and Scheme are many things, but hardly common ;) – Cheadle

ruby has ===. It has been too long for me to remember if it does the same thing. – Lvov

Also, livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/… for actionscript. Basically, google "strict equality". – Falsecard

Answer 6

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

Dispersive

Answer 7

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.

Becky

Answer 8

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.

Armful

Answer 9

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%
---------------------------------------------------

Wilen

Answer 10

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

Fecundity

Answer 11

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_)

Stupa

Answer 12

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

Albumin

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. – Orel