[Stratoscope]

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-1]

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.

[Stratoscope]

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!

[cygx]

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-1]

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

[cygx]

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-1]

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

[Stratoscope]

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)