Conversions in Javascript

Posted 249 days ago ·  Tagged: · 6 Comments

Using Javascript has an ease, you can achieve the same result by doing it in different ways. Here am going to discuss about the performance implications of the same. Lets start with string to number conversion. The usual way of string to number conversion is done using parseInt. However there are someother ways it can be done as well

var n1 = parseInt("12");
var n2 = Number("12");
var n3 = +"12";
var n4 = ~~(1*"12");

All of the above does the same job and n1==n2==n3==n4. So, of all the ways we have to see which one is the ideal way to do that. This is where performance is a big consideration. In this jsperf test we can see which one performs well. Of four of them the last wicked way performs well in all browsers except chrome and safari webkit browsers(I don’t know why). At the end the best way is to use the parseInt, somebody might prefer using +”Value” for ease of typing. However should know the performance benefits of the other ways. Similarly, string conversion

var date = new Date();
var ds = date.toString();
var dr = date+"";

In this case ds==dr, the way toString works is faster in most cases.

6 Comments

  1. Florian
    September 16, 2012 at 6:21 pm · Reply

    parseInt(’8′) –> 8
    parseInt(’08′) –> 0
    parseInt(’010′) –> 8
    parseInt(’0×10′) –> 16

    Same applies for new Number.

    Don’t use parseInt/new Number without the second argument to specify numeric base, or it’ll apply willy-nilly guesses which ones leading to funny results of anything.

  2. kybernetikos
    September 16, 2012 at 7:39 pm · Reply

    parseInt is not doing the same thing the other methods are doing. For example, Number(“2px”) is NaN, but parseInt(“2px”, 10) is 2.

    The key difference is that Number (and the implicit conversions) will try to convert the whole thing, and if they fail will return NaN, while parseInt will parse as much as it can and return that.

  3. some
    September 16, 2012 at 8:09 pm · Reply

    Please note that all logical operators like ~, <>, >>>, & and | internally operates on a 32 bit integer, while Numbers in javascript is 64 bit floats. Try to convert “2147483648″ and notice the sign.

    Check out the jsperfs page for other variants.

    However, I’m not sure if the numbers given by jsperf is accurate in this case. When using randomized data I don’t get that much of a difference between the different methods. I would like to see the code that jsperf is running. I think there might be a hidden compilation that we don’t see:
    Try this:

    Function(“return ~~(1*’12′)”).toString();

    In firefox I get:

    function anonymous() { return 12;}

    Notice that the expression has been compiled to 12. No wonder that it is faster!

    • some
      September 16, 2012 at 9:05 pm · Reply

      I created a new jsperf that does the conversion from a string stored in a variable instead of a literal string. There parseInt is faster in Firefox, Opera, Chrome and Safari. Surprisingly it is the slowest in IE, where +str is the fastest.

      Also note that “Number” only takes one parameter (but “parseInt” takes two). In one of the tests that where added to your jsperf there was one that did “0+’12′”. That actually returns a string.

      Here is the link to my updated jsperf:
      http://jsperf.com/parse-number-from-string

      • cygx
        September 17, 2012 at 7:33 am · Reply

        > In one of the tests that where added to your jsperf there was one that did “0+’12′”. That actually returns a string.

        That was me, even if I should have known better: I wanted to test if binary plus suffers from the same poor performance in Firefox as unary plus, but forgot about the fact that Javascript’s plus genrally doesn’t force numeric conversions. I blame it on too much Perl coding :) .

        I couldn’t see any pattern in the set of operators which are fast (eg ~~’12′, ’12′-0, ’12′<<0) and those which aren't (eg +'12', '12'|0).

Leave a Comment

*