JavaScript performance difference between double equals (==) and triple equals (===)

Question

• If the types compared are the same, they are identical. That is to say they use the exact same algorithm.

• If the types are different, then performance is irrelevant. Either you need type coercion, or you don't. If you don't need it, don't use == because the result you get may be unexpected.

Strict comparison (===) will always be slightly faster, but the difference is usually negligible.

It definitely makes sense to prefer === if you know for certain that you don't need type coercion in the comparison. It will always be at least as fast as ==.

Edit: for reference here's the by the spec explanation by Dr. Axel Rauschmayer http://www.2ality.com/2011/06/javascript-equality.html Really great write up.

=== (Strict Equality): Only considers values equal that have the same type.

1. undefined === undefined, null === null,
2. NaN === nothing including itself,
3. Primitive [Number|String|Boolean] === primitive value equal,
4. to self (+0 === -0)
5. Two objects [Array|Object|Function] === Only self (same exact entity)

== (Lenient Equality)

1. If both values have the same type: compare with ===.
2. undefined == null
3. number and string: string => number and compare
4. boolean and non-boolean => non-boolean to number and compare
5. string or number => an object: convert object to primitive and comparison.

In all modern Javascript environments they are implemented completely different. In simple terms, == tests for alikeness via converting given variables into primitives (string, number, boolean). === tests for strict sameness, which means exact same Object or primitive value without conversion.

If you do objOne == objTwo what actually happens is [[EQUALS]].call(objOne.valueOf(), objTwo.valueOf())

The resolution of valueOf can be somewhat involved, bouncing between functions exposed in JS and internal engine stuff. Suffice to say that the comparison will always end up with two values coerced to primitive or an error will be thrown.

Edit: EQUALS actually tries STRICT_EQUALS first which preempts the rest of the process.

The interesting bit here is that valueOf (and its partner toString) are overridable. Run this piece of code in Chrome (I think any webkit, not sure if JSC and V8 share this tidbit). It will blow your mindpiece:

var actions = [];
var overload = {
  valueOf: function(){
    var caller = arguments.callee.caller;
    actions.push({
      operation: caller.name,
      left: caller.arguments[0] === this ? "unknown" : this,
      right: caller.arguments[0]
    });
    return Object.prototype.toString.call(this);
  }
};
overload.toString = overload.valueOf;
overload == 10;
overload === 10;
overload * 10;
10 / overload;
overload in window;
-overload;
+overload;
overload < 5;
overload > 5;
[][overload];
overload == overload;
console.log(actions);

Output:

[ { operation: 'EQUALS',
    left: overload,
    right: 10 },
  { operation: 'MUL',
    left: overload,
    right: 10 },
  { operation: 'DIV',
    left: 'unknown',
    right: overload },
  { operation: 'IN',
    left: overload,
    right: DOMWindow },
  { operation: 'UNARY_MINUS',
    left: overload,
    right: undefined },
  { operation: 'TO_NUMBER',
    left: overload,
    right: undefined },
  { operation: 'COMPARE',
    left: overload,
    right: 5 },
  { operation: 'COMPARE',
    left: 'unknown',
    right: overload },
  { operation: 'ToString',
    left: 'unknown',
    right: overload } ]

The essence of the difference between == and === is illustrated by === not showing up in that list. It skips the journey into JavascriptLand entirely. That adventure is expensive when comparing performance.

However you need to account for engine optimizations. For most objects, the engine will be able to cut out most of the steps and stay in NativeLand and get almost the same performance. But this isn't a guarantee and if something prevents the engine from being able to use the optimizations, some fancyness in your code or overriding the builtins or a myriad of issues, then you instantly see the result in performance. === forces it.

=== is just about the only immutable thing in Javascript.

Due to performance, I think === has better performance, because === is stricter than ==,

e.g. try the following in the Chrome console.

> 1 == '1'
  true
> 1 === '1'
  false

== has to check more things than ===

From some flimsy tests, == appears to be marginally quicker than ===.

By marginally, I mean that I can see a few milliseconds difference on interations of many millions of tests. You can't possibly need the performance gain, rather than using whatever is most correct for the task at hand.

EDIT: actually, seems to depend on /what/ you're comparing and the browser implementation. In other words, don't worry about it.