Order of comparision

[howa]

I see some codes in YUI library is extensively using

i.e.

if ( "undefined" == typeof xxx )

instead of

if ( typeof xxx == "undefined" )


Is the first one faster?

 

[Henry]

I see some codes in YUI library is extensively using

i.e.

if ( "undefined" == typeof xxx )

instead of

if ( typeof xxx == "undefined" )

Is the first one faster?

No. The first is used because if it is typoed as - "undefined" =
typeof xxx - (missing one of the equals signs) you get a syntax error
while if you typeof the second as - typeof xxx = "undefined" - the
syntax is fine but the result is the equivalent of - typeof (xxx =
"undefined") - which is an expression with the value "string", and so
is always true.

 

[David Mark]

I see some codes in YUI library is extensively using

You'll see all sorts of things in there.

i.e.

if ( "undefined" == typeof xxx )

instead of

if ( typeof xxx == "undefined" )

Is the first one faster?

I seriously doubt it.

 

[Jeremy J Starcher]

I see some codes in YUI library is extensively using

i.e.

if ( "undefined" == typeof xxx )

instead of

if ( typeof xxx == "undefined" )


Is the first one faster?

I doubt that it is faster, even in some of the newer Javascript
environments.

Let me show you another example, and you'll see why people use it. (Then
I'll tell you why I don't.)

if (a == 5) {...} // Note the comparison
if (a = 5) {...} // Legal, but prolly not what you want.

if (5 == a) {...} // The same comparison
if (5 = a) {...} // Either syntax or runtime error. Can't assign to a
constant.

My comments on the second form:
a) I read it slower. My brain isn't wired that way and I have to
think about it.
b) The trick fails to catch '=' vs '==' if you are comparing two
variables.

 

[The Natural Philosopher]

I doubt that it is faster, even in some of the newer Javascript
environments.

Let me show you another example, and you'll see why people use it. (Then
I'll tell you why I don't.)

if (a == 5) {...} // Note the comparison
if (a = 5) {...} // Legal, but prolly not what you want.

if (5 == a) {...} // The same comparison
if (5 = a) {...} // Either syntax or runtime error. Can't assign to a
constant.

My comments on the second form:
a) I read it slower. My brain isn't wired that way and I have to
think about it.
b) The trick fails to catch '=' vs '==' if you are comparing two
variables.

cant say about how an interpter does this, but in a compiled language
chances are for an integer comparison you will load a register with the
value and compare it with a constant. Or load the constant into another
register, if the opcode set doesn't allow comparison between other than
registers.

wouldn't mind a stab that in interpreted language the whole thing
becomes if (isequal(a,b)) with no particular reason to prefer one order
over another. or maybe that the right hand side gets type cast to teh
type of the left, is how it works if the typing is loose. so whatever is
simplest should be on the left hand side.

so (probably wrong syntax) if ('5'> a) is slower than if(5> a) as the
former implies a string conversion.

 

[Dr J R Stockton]

In comp.lang.javascript message <1a8cc184-4f21-4053-81bd-6fa932067277@x1
6g2000prn.googlegroups.com>, Tue, 16 Dec 2008 08:23:03, howa

I see some codes in YUI library is extensively using

i.e.

if ( "undefined" == typeof xxx )

instead of

if ( typeof xxx == "undefined" )


Is the first one faster?

If you cannot test that yourself, you have simpler things to learn
first. If you do test it and cannot see a difference, it does not
matter which might be faster.

In Opera 9.27, after var U, xxx ,
xxx == U xxx === U are faster. You should consider what they
may mean.

 

[Jeremy J Starcher]

cant say about how an interpter does this, but in a compiled language
chances are for an integer comparison you will load a register with the
value and compare it with a constant. Or load the constant into another
register, if the opcode set doesn't allow comparison between other than
registers.

In a *strongly* typed language (and for purposes of this discussion, C is
strongly typed), the type of variable is known at compile time and allows
the compiler to choose between solutions.

As for loading into a register or comparing two memory locations, that
depends upon if the target platform even HAS registers (not all do) and
if giving up a register is worth the speed advantage.

wouldn't mind a stab that in interpreted language the whole thing
becomes if (isequal(a,b)) with no particular reason to prefer one order
over another. or maybe that the right hand side gets type cast to teh
type of the left, is how it works if the typing is loose. so whatever is
simplest should be on the left hand side.

That is just about how my interpreter does it. (My compiler is for a
strongly typed language, so I don't do casting here, but it would be easy
enough to cast v2 to integer.)

(from my code)

function integer_equal()
{
// Parameters: (p3, .. p1) V_INTEGER+V_INTEGER+V_ILLEGAL
// Returns: V_BOOLEAN
var v1 = VarStack.pop();
var v2 = VarStack.pop();

var r = new C_BOOLEAN(v2.value == v1.value)
VarStack.push(r);
}

so (probably wrong syntax) if ('5'> a) is slower than if(5> a) as the
former implies a string conversion.

Don't forget, it also has to CHECK if it needs converted or not. Good
odds that '===' would be fastest yet, but I'd not wage the house on it.

 

[RobG]

[...]
wouldn't mind a stab

No need to guess, read the spec.

that in interpreted language the whole thing
becomes if (isequal(a,b)) with no particular reason to prefer one order
over another. or maybe that the right hand side gets type cast to teh
type of the left,

It is not left up to the implementation to decide which way to cast
different types, nor is it dependant on the order. ECMA-262 it says:

11.9.1 The Equals Operator ( == )
The production EqualityExpression : EqualityExpression ==
RelationalExpression is evaluated as follows:
1. Evaluate EqualityExpression.
2. Call GetValue(Result(1)).
3. Evaluate RelationalExpression.
4. Call GetValue(Result(3)).
5. Perform the comparison Result(4) == Result(2). (Section 11.9.3.)
6. Return Result(5).

Section 11.9.3 says:

1. If Type(x) is different from Type(y), go to step 14.
[... since we are discussing different types ...]
14. If x is null and y is undefined, return true.
15. If x is undefined and y is null, return true.
16. If Type(x) is Number and Type(y) is String,
return the result of the comparison x == ToNumber(y).
17. If Type(x) is String and Type(y) is Number,
return the result of the comparison ToNumber(x) == y.
18. If Type(x) is Boolean, return the result of the comparison ToNumber
(x) == y.
19. If Type(y) is Boolean, return the result of the comparison x ==
ToNumber(y).
20. If Type(x) is either String or Number and Type(y) is Object,
return the result of the comparison x == ToPrimitive(y).
21. If Type(x) is Object and Type(y) is either String or Number,
return the result of the comparison ToPrimitive(x) == y.
22. Return false.

So there are quite explicit rules on how to do type conversions where
the comparison is between different types.

is how it works if the typing is loose. so whatever is
simplest should be on the left hand side.

That isn’t how it works - Henry has the answer.

so (probably wrong syntax) if ('5'> a) is slower than if(5> a) as the
former implies a string conversion.

From the spec you can see that if one is Number and the other String,
the string is converted to a number, always, regardless of the order
of the comparison.