18

See these tests:

random
  • 9,774
  • 10
  • 66
  • 83
Thanh Nguyen
  • 5,174
  • 11
  • 43
  • 74
  • 13
    Because it doesn't have to do type casting, so it knows faster if condition is true or false. – elclanrs Sep 27 '13 at 02:52
  • 1
    Running these in Chrome shows no significant difference. –  Sep 27 '13 at 02:57
  • 8
    The links you posted don't really support your statement. The results show that on most browsers they are relatively equivalent, a few show == as faster, and a few show === as faster. – bcorso Sep 27 '13 at 02:57
  • 1
    @MikeW first run for chrome showed no significant difference for me, however, second run it showed a 22% difference. `===` being slower. Odd. – Kyle Muir Sep 27 '13 at 02:58
  • 1
    I think a bigger question might be, "why has Chrome gotten slower running these commands with each release?" – bcorso Sep 27 '13 at 03:01
  • See http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons?lq=1 and various other linked questions on the same lines – John Carter Sep 27 '13 at 03:01
  • @bcorso: To make Dart seem faster perhaps? Actually, we don't know that the tests were run on the same computer. – user2736012 Sep 27 '13 at 03:02
  • 3
    Because it's easier to ask with minimal effort than to search http://stackoverflow.com/questions/12374815/javascript-vs-operators-performance http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons http://stackoverflow.com/questions/10259774/vs-in-a-remote-javascript-file-which-one-is-faster http://stackoverflow.com/questions/12332855/which-javascript-equality-operator-or-is-faster http://stackoverflow.com/questions/3900575/difference-between-and-in-java-script – random Sep 27 '13 at 03:05
  • 4
    Nothing to do with the quesiton, but JS performance is so inconsistent across browsers. Not only that but it often defies common sense, such as regular expressions being faster to parse a string than performing a simple character per character parsing, mostly because some native methods are written in C where it executes faster. That's extremely annoying. – plalx Sep 27 '13 at 03:06
  • 2
    The performance difference is trivial and browsers are implemented in different ways. Those tests can't possibly reflect real world applications. I just use `==` and `===` when it makes sense. – elclanrs Sep 27 '13 at 03:09
  • @elclanrs It's funny how when you start writing JavaScript, you often start using `==`, then you learn about `===` and consider `==` as evil, until you *master* the language and embrace both ;) – plalx Sep 27 '13 at 03:15

3 Answers3

33

Here's what javascript has to do for ===:

  1. If Type(x) is different from Type(y), return false.
  2. If Type(x) is Undefined, return true.
  3. If Type(x) is Null, return true.
  4. If Type(x) is Number, then
    1. If x is NaN, return false.
    2. If y is NaN, return false.
    3. If x is the same Number value as y, return true.
    4. If x is +0 and y is −0, return true.
    5. If x is −0 and y is +0, return true.
    6. Return false.
  5. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions); otherwise, return false.
  6. If Type(x) is Boolean, return true if x and y are both true or both false; otherwise, return false.
  7. Return true if x and y refer to the same object. Otherwise, return false.

And here's what it has to do for ==:

  1. If Type(x) is the same as Type(y), then
    1. If Type(x) is Undefined, return true.
    2. If Type(x) is Null, return true.
    3. If Type(x) is Number, then
      1. If x is NaN, return false.
      2. If y is NaN, return false.
      3. If x is the same Number value as y, return true.
      4. If x is +0 and y is −0, return true.
      5. If x is −0 and y is +0, return true.
      6. Return false.
    4. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions). Otherwise, return false.
    5. If Type(x) is Boolean, return true if x and y are both true or both false. Otherwise, return false.
    6. Return true if x and y refer to the same object. Otherwise, return false.
  2. If x is null and y is undefined, return true.
  3. If x is undefined and y is null, return true.
  4. If Type(x) is Number and Type(y) is String, return the result of the comparison x == ToNumber(y).
  5. If Type(x) is String and Type(y) is Number, return the result of the comparison ToNumber(x) == y.
  6. If Type(x) is Boolean, return the result of the comparison ToNumber(x) == y.
  7. If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).
  8. If Type(x) is either String or Number and Type(y) is Object, return the result of the comparison x == ToPrimitive(y).
  9. If Type(x) is Object and Type(y) is either String or Number, return the result of the comparison ToPrimitive(x) == y.
  10. Return false.

Notice that if Type(x) equals Type(y) then the operators do the same thing. However, if they aren't, then the == might have to do various conversions whereas === just returns false.

For the links you gave, the types that are being compared are actually the same, so the two operators should perform about equally. Differences here would be based on implementation details - since they do different things, they can be optimized for differently. Theoretically, since === does less, one would think it would always be faster, but that doesn't appear to be the case for certain builds of Firefox, at least if those benchmarks are accurate.

However, see the difference if the types are different. When doing "hi" === {} you get ~66 million ops/second, but for "hi" == {} you only have ~4 million ops/second.

Claudiu
  • 224,032
  • 165
  • 485
  • 680
8

JavaScript is a weakly typed language, so it will apply type coercion wherever possible.

Equals Operator

// These are true
new Number(10) == 10; // Number.toString() is converted
                      // back to a number

10 == '10';           // Strings gets converted to Number
10 == '+10 ';         // More string madness
10 == '010';          // And more 
isNaN(null) == false; // null converts to 0
                      // which of course is not NaN

The Strict Equality Operator

It works like the normal equality operator, except that strict equality operator does not perform type coercion between its operands.

""           ===   "0"           // false
0            ===   ""            // false
0            ===   "0"           // false
false        ===   "false"       // false
false        ===   "0"           // false
false        ===   undefined     // false
false        ===   null          // false
null         ===   undefined     // false
" \t\r\n"    ===   0             // false

The above results are a lot clearer and allow for early breakage of code. This hardens code to a certain degree and also gives performance improvements in case the operands are of different types.

So === faster than == in Javascript

Here is good Reference

Deepak Ingole
  • 14,912
  • 10
  • 47
  • 79
3

=== compares if the values and the types are the same.
== compares if the values are the same, but it also does type conversions in the comparison. Those type conversions make == slower than ===.

JKor
  • 3,822
  • 3
  • 28
  • 36