double vs triple equals

JavaScript performance comparison

Test case created by John-David Dalton

Info

Testing the perf difference between == and ===.

Preparation code

 
<script>
Benchmark.prototype.setup = function() {
    var r;
    var number = 1;
    var string = '1';
};
</script>

Test runner

Warning! For accurate results, please disable Firebug before running the tests. (Why?)

Java applet disabled.

Testing in unknown unknown
Test Ops/sec
triple w/ like values
r = string === string;
pending…
double w/ like values
r = string == string;
pending…
tripple w/ unlike values
r = string === number;
pending…
double w/ unlike values
r = string == number;
pending…

Compare results of other browsers

Revisions

You can edit these tests or add even more tests to this page by appending /edit to the URL. Here’s a list of current revisions for this page:

3 comments

John-David Dalton (revision owner) commented :

By spec (here and here) both == and === should perform the same number of steps when comparing like type values.

The point of this test is to show that even though there are micro differences there is no real world performance concern for using === over == as the lowest ops/sec are still in the millions of operations a second. You should use the correct operator for the job.

Jussi Kalliokoski commented :

The test looks way too simple, I'd be surprised if modern engines didn't know better to convert those triple equals to something like !isNaN(variable). Comparing something to itself doesn't give a very reliable performance test, too many unknown vectors.

Instead, more varying values should be used. That said, I'd still trust the results of the test to some extent. But the myth here is hardly busted, in Firefox triple equals results are 20x as fast (at least if I understand jsperf correctly).

But even that said, I agree, use the correct operator for the job. defaultonnullorundefined == null is especially handy sometimes.

Jussi Kalliokoski commented :

And another thing is that even if the number of steps in the spec is the same, it doesn't mean it translates to the same amount of processor instructions. The triple equals can be made into a big switch branch that has early returns and simpler nesting, whereas the double equals has to make more complex nested rules and can't have as early returns. The triple equals also benefits more from predictive branching which is something that also makes the results of this tests a bit less meaningful.

Add a comment