This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.

Check out a free preview of the full Deep JavaScript Foundations course:
The "Double vs. Triple Equal Performance" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

Kyle explains the performance impacts of double and triple equal operator. Afterward, Kyle shares some pro-tips about how to determine when this operator should be used.

Get Unlimited Access Now

Transcript from the "Double vs. Triple Equal Performance" Lesson

>> Kyle Simpson: All right, what about the performance? Sometimes it's cited, well, triple equal's gonna be more performance, we should use it. Let's go back to that misconception earlier when I said, many people say, that double equals checks the value, and triple equals checks the value and the type, you remember that?

[00:00:17] In that statement, which one of those two appears to do more work?
>> Speaker 2: Triple equals.
>> Kyle Simpson: Triple equals, okay? But then we've already established that's incorrect. The spec says, it's incorrect. So what actually happens is that, double equals allows coercion and triple equals disallows coercion. Which one of those appears to do more work?

>> Speaker 2: Double.
>> Kyle Simpson: Double, so thinking critically about this stuff, it actually matters how it really works cuz we can come to an entirely opposite intuition.
>> Kyle Simpson: Now, I'm actually gonna argue that the performance doesn't matter, but I just wanna observe the performance for a moment.
>> Kyle Simpson: The double equals is going to be slower, but only under some circumstances.

[00:01:02] Back to the spec, if the types are the same, did you know that double equals does exactly the same thing as triple equals?
>> Kyle Simpson: If the types are already the same, double equals and triple equals do exactly the same thing. There will be zero performance difference.
>> Kyle Simpson: Just one less character to type, if the types are the same.

[00:01:28] So the question you have to ask yourself is, how often do I make comparisons where I know the types are already gonna be the same?
>> Kyle Simpson: Honestly, I think you ought to do more of that. Honestly, I think it's better to do comparison where you already know what the types are.

[00:01:44] Coercion is helpful in those places where you can't avoid it, but it's not like you should go around looking for every opportunity to do some kind of crazy coercion.
>> Kyle Simpson: So if you can get to the point where the types are already the same, then double equals is guaranteed to be safe cuz it's the same thing as triple equals, okay?

[00:02:03] So it's not gonna be slower in all cases. It's only gonna be slower in cases where the types are different.
>> Kyle Simpson: But, the real question is not whether or not it's slower. The real question is whether or not we want that coercion. Let's test this theory of whether or not double equals is actually in an overall case gonna be slower.

[00:02:25] Let's imagine we have a number comparison to a string comparison. These types differ. x and y are the same type, but x and z is definitely of a different type. A coercion is going to occur to allow that comparison to happen. There is no question that coercion will take some time.

[00:02:43] We're talking about microseconds, but it is slower, okay, no question. Many people stop there and say, end of story. If double equals a slower in any circumstance, I'm always gonna use triple equals.
>> Kyle Simpson: They fail to account for one very important fact. Triple equals is not more than twice as fast as double equals, it's about 30% faster than double equals.

>> Kyle Simpson: You might be able to guess where I'm going. x == to z and x === to z are not equivalent, they don't have the same behavior. So comparing the performance is like comparing an apple and an orange. Let's compare equivalences.
>> Kyle Simpson: This is the equivalence. You could either do x == to y, or you could do x === to y, or x === to z.

[00:03:38] So you could either do one double equals comparison, or you could do two triple equals comparisons.
>> Kyle Simpson: Now, if we do 2 versus 1, which one of those 2 lines? Is line 2 or line 6 gonna be faster?
>> Kyle Simpson: Line 2 is actually gonna be faster, because triple equals is not more than double as fast as double equals.

>> Kyle Simpson: So, actually, if we really care about microseconds, you ought to prefer double equals.
>> Kyle Simpson: Cuz, on the whole, the equivalence, it's gonna be faster to use coercion. This actually should fit with some intuition of yours which I've said over and over and over again, let the engine do what it's best at.

>> Kyle Simpson: The engine is better at doing coercion faster than you are able to list these things out explicitly.
>> Kyle Simpson: It's just a fact.
>> Kyle Simpson: Let the engine do what it's better at.
>> Kyle Simpson: But, even though double equals is faster, that's not the argument I'm actually making, I just wanted to debunk the other argument.

>> Kyle Simpson: I think this comment sums it up well. If the types compare to the same, they are identical, that is to say, they use the same exact algorithm. If the types are different, the performance is irrelevant, either you need type conversion or you don't. If you don't need it, don't use == because the result you get maybe unexpected.

>> Kyle Simpson: Every frame's the whole debate, doesn't it? Doesn't it actually put the responsibility back on you to be the responsible engineer and critically think about it? Do I want coercion or do I not?
>> Kyle Simpson: So the FUD, the fear, uncertainty and doubt that is often spread throughout this, is that using == in your code is dangerous and you should avoid it.

>> Kyle Simpson: That's the FUD. Let me reword that as a protip. Use === where it's safer and use == where it's more helpful.
>> Kyle Simpson: And let me extract that. Let me extrapolate that same comparison to the larger topic of coercion.
>> Kyle Simpson: JavaScript's implicit coercion is flaw in the design of the language, avoid it.

[00:05:53] That's a near direct quote from the good parts.
>> Kyle Simpson: Let's reword that.
>> Kyle Simpson: Use explicit coercion where it's safer and use implicit coercion where it's more helpful.
>> Kyle Simpson: Still use coercion. Choose between them depending upon which one is more helpful or more safe depending on the needs of each statement.

>> Kyle Simpson: And guess what? That's something your linters not gonna be smart enough to figure out, you're gonna have to figure that out.