Conversions in Javascript(thetascript.com)

10 pointsby vetri0214 anni fa13 comments

http://thetascript.com/conversions-in-javascript/

13 comments

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 meaningless. After all, this is also true:

  '12' == 12

* The "wicked" method, ~~( 1 * '12' ), smacks of cargo cult programming. No mention of the fact that it uses two operators instead of one? Why not test the two separately:

  1*'012.78'  // 12.78
  ~~'012.78'  // 12

Complaints aside, the results for the "wicked" method certainly are interesting. Why is it (along with the two variations above) so extremely fast in Firefox?

Here's an updated jsperf with those additional test cases:

http://jsperf.com/parsenumber/5

some-114 anni fa

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 it. That's why it is so much faster. The same is true for "<<", ">>" and "1 * '12'"

I created another test where it actually do the conversion, by assigning the string to a variable and use that in each test. There parseInt is faster in Firefox, Opera, Chrome and Safari. Surprisingly it is the slowest in IE, where +str is the fastest.

You can find it here: http://jsperf.com/parse-number-from-string

Also notice:

* All the logical operators (~, <<, >>, |) operates internally on a 32 bit signed integer, while parseInt, Number and + operates on a 64 bit signed float. Try to convert 2147483648 or 2333444555 for a little surprise.

* At the other jsperf someone added "0+'12'". That returns a string, not a number.

Stratoscope14 anni fa

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!

cygx14 anni fa

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...

some-114 anni fa

-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.

cygx14 anni fa

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?

some-114 anni fa

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

Stratoscope14 anni fa

Other folks have jumped in and improved those tests. It's up to revision 10 now:

http://jsperf.com/parsenumber/10

(scroll down the page to find any newer revisions)

FuzzyDunlop14 anni fa

One might prefer to supply the radix when using parseInt(), too. Lest one encounters strings that convert into octal numbers.

parseInt('09') !== parseInt('9')

cygx14 anni fa

Except for n2 and n3, all of these have different semantics.

Performance doesn't help if your code is wrong.

turshija14 anni fa

Firefox results are amazing, "wicked" is over 20x faster then any other method ...

froball14 anni fa

Why people are so keen on micro-optimizing their code? The bottleneck lies on DOM, not on your conversions.

Herover14 anni fa

I guess that depends on what you are doing.

If you have a 10k csv file and want to make a graph using javascript, I believe it could come handy.