5
I’m using the Jslint to check if the Javascript source code complies with the coding rules, and it is returning many suggestions to replace == (two signs of equals) with === (three signs of equals) when doing things like comparing idlol.value.length == 0 on parole if.
There is a performance benefit to replacing == for === ?
If no type conversion occurs, there will be a performance gain in relation to == ?
6
I did a little test on Node.js V9.8.0:
"use strict";
let t0, t1, dummy;
t0 = (new Date()).getTime();
dummy = true;
for (let i = 0; i < 10000000; ++i) {
let j = "" + i;
let k = 0 + i;
dummy = dummy || (i == k);
}
t1 = (new Date()).getTime();
console.log("" + (t1 - t0) + "ms " + dummy);
t0 = (new Date()).getTime();
dummy = true;
for (let i = 0; i < 10000000; ++i) {
let j = "" + i;
let k = 0 + i;
dummy = dummy || (i === k);
}
t1 = (new Date()).getTime();
console.log("" + (t1 - t0) + "ms " + dummy);
t0 = (new Date()).getTime();
dummy = true;
for (let i = 0; i < 10000000; ++i) {
let j = "" + i;
let k = 0 + i;
dummy = dummy || (i == j);
}
t1 = (new Date()).getTime();
console.log("" + (t1 - t0) + "ms " + dummy);
t0 = (new Date()).getTime();
dummy = true;
for (let i = 0; i < 10000000; ++i) {
let j = "" + i;
let k = 0 + i;
dummy = dummy || (i === j);
}
t1 = (new Date()).getTime();
console.log("" + (t1 - t0) + "ms " + dummy);
The longest time is consumed by the creation of the j string. The results on my machine were as follows::
883ms # int == int verdadeiro
1006ms # int === int verdadeiro
1030ms # int == string verdadeiro
1016ms # int === string falso
Surprisingly, the == operator was faster than ===, but only when the two objects being compared are already of the same type. But it’s a tiny difference (12ns by comparison). Values should be different in a browser or in different versions of Node.js.
This difference makes sense since the operator ===, In addition to checking the value, it also checks the type of variables
I expected === to be faster because checking the type is faster than the value, but anyway, living and learning :)
By the nature and specification of each operator, === tends to be faster, is undeniable. If it is comparison of the same type, they have the same exact steps in the comparison algorithm. Your test needs more samples, each test only lasts 1 second. It cannot be taken as a reliable and stable stasis test. I’ve even been around here several times and each time gave divergent results.
@Guilhermecostamilam does not make sense no, quite the opposite. The algorithm of === is contained in that of ==. A string "6" is stored with value other than a number 6. There is no way to compare value without checking its type first, and that’s what the algorithm == need to do in its additional steps if the two objects are not of the same type, it converts the object to compare for the same type of compared to make the check.
Just reinforcing @Andrefigueiredo’s statement: follows their algorithms Abstract Equality Algorithm (a.k.a ==) and the Rigorous Equality Algorithm (a.k.a ===)
By removing the useless "Let j..." from the first two tests, the === gets fast msis (25ms x 20ms). Operation optimization should change. On the other hand, removing "Let k..." from the last two tests widens the difference in favor of ==. You really can’t trust the numbers too much.
3
I believe you’re referring to the rule eqeq.
The reason for this rule is not because it wants to gain performance, but to improve cohesion, after all the Algorithm of Abstract Equality is quite obscure, to get an idea, the following comparisons return true:
[] == false
[] == ![]
3 == "03"
In any case, you can create some exceptions to this rule, such as comparisons with null or between literais
smart - comparison between literals
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Always, except null - comparison with null
/*eslint eqeqeq: ["error", "always", {"null": "ignore"}]*/
foo == null
Browser other questions tagged javascript operators
You are not signed in. Login or sign up in order to post.
I don’t remember any of them and I doubt that Jslint will make any suggestions for performance, even more of a micro-optimization. See more at https://answall.com/questions/7/qual-a-difference-entre-os-operatorss-e-em-javascript
– Andre Figueiredo
I just don’t remember now, but I saw a page that benchmarks these operators, and the
==stands in front of the===.– Sam
@dvd, that question exists in Brothers but I did not find the answers clear enough, even because my English is bad. Check out the Brothers https://stackoverflow.com/questions/359494/which-equals-operator-vs-should-be-used-in-javascript-comparisons
– user60252
I’ve seen it before. D
– Sam