Live data from Hacker News

Conversions in Javascript

thetascript.com

11–14 of 14 posts

Re: Conversions in Javascript

#11
post #8

This article has a few problems. * "All of the above does the same job...". Not true at all; the four examples do three very different things. Try them with a more interesting string argument, say '012.78': parseInt('012.78') // 10 (number interpreted as octal integer) Number('012.78') // 12.78 +'012.78' // 12.78 ~~(1*'012.78') // 12 * "...and n1==n2==n3==n4" Using == instead of === here makes the statement meaningle…

In general, using operators will speed things up as these can be statically dispatched. No idea why +'12' is so slow, though - 0+'12' doesn't suffer from this...

-0+'12' (and 0+'12') doesn't convert it to a number, it converts the zero to a string and then concatenate them to the string "012". And Firefox optimize it:

  Function('return -0+"12"').toString();
Returns:

  "function anonymous() { return "012";}"
So there is no conversion going on in the test, it just returns the string "012". No wonder that it is fast. See my comment above for another jsperf where it is converted in each test.

Re: Conversions in Javascript

#12
post #10

This article has a few problems. * "All of the above does the same job...". Not true at all; the four examples do three very different things. Try them with a more interesting string argument, say '012.78': parseInt('012.78') // 10 (number interpreted as octal integer) Number('012.78') // 12.78 +'012.78' // 12.78 ~~(1*'012.78') // 12 * "...and n1==n2==n3==n4" Using == instead of === here makes the statement meaningle…

The reason why the wicked is so fast in Firefox is because of the literal string and the optimizations done by the compiler. Try this (creates a function and then show the source): Function('return ~~(1 * "12");').toString(); And you get this result: "function anonymous() { return 12; }" Notice that the expression has been converted to 12 in the function, so each call to it will just return 12 instead of converting i…

Ah, thank you very much. This is one of those things that is so obvious in hindsight: don't run performance tests using constant values, or the compiler may optimize the code away!

Re: Conversions in Javascript

#13
post #11
post #8

Earlier quoted context omitted.

In general, using operators will speed things up as these can be statically dispatched. No idea why +'12' is so slow, though - 0+'12' doesn't suffer from this...

-0+'12' (and 0+'12') doesn't convert it to a number, it converts the zero to a string and then concatenate them to the string "012". And Firefox optimize it: Function('return -0+"12"').toString(); Returns: "function anonymous() { return "012";}" So there is no conversion going on in the test, it just returns the string "012". No wonder that it is fast. See my comment above for another jsperf where it is converted in…

Damn - too much Perl coding recently, where + is always arithmetic.

However, my point still stands: Why are some operators (and in particular unary minus, which is probably the most commonly used one) so much slower than others?

Re: Conversions in Javascript

#14
post #13
post #11

Earlier quoted context omitted.

-0+'12' (and 0+'12') doesn't convert it to a number, it converts the zero to a string and then concatenate them to the string "012". And Firefox optimize it: Function('return -0+"12"').toString(); Returns: "function anonymous() { return "012";}" So there is no conversion going on in the test, it just returns the string "012". No wonder that it is fast. See my comment above for another jsperf where it is converted in…

Damn - too much Perl coding recently, where + is always arithmetic. However, my point still stands: Why are some operators (and in particular unary minus, which is probably the most commonly used one) so much slower than others?

See the following comment: http://news.ycombinator.com/item?id=4530557

The reason why some of them is so fast is because the constant expression is evaluated to a constant, so instead of doing a conversion in the test, the already converted number is returned.

Use this test instead: http://jsperf.com/parse-number-from-string

Post reply on HN