DEV Community

You should stop using `parseInt()`

Alessio Michelini on October 14, 2021

This is something I see all the times, you have some code where at some point you have a variable that contains a number, maybe it comes from a for...

Read full post

Kyle Stephens • Oct 14 '21 • Edited

Unless you're doing this in the order of hundreds of thousands, performance is neglible (I've rarely come across use cases like this in prod systems)

While it's nice to think about these things and how you write code, I will always push back on people looking to enforce issues or 'standards' like this in PRs because they're rather subjective POV on style or rely on contrived performance benefits. If this seems like a harsh response, I apologise, but I'm wary of articles with titles like you 'should' be doing this, or you 'must not' do this, etc.

Max Ziebell • Oct 15 '21

This is so true. Instead of pushing back just add a math.round to the Number() and the readability suffers and probably the performance too. I agree, the suggested „optimization“ is not worth implementing and worth thinking about in most real world use cases.

lionel-rowe • Oct 15 '21 • Edited

there are of course use cases where it’s beneficial to use it, for example if you want to extrapolate an integer out of a floating number, which is a good 50% faster than Math.round().

Two things here -

parseInt doesn't do any rounding, only truncation. The equivalent Math function would be Math.trunc:

Math.round('0.999') // 1
Math.trunc('0.999') // 0
parseInt('0.999')   // 0

Math.round('-0.999') // -1
Math.trunc('-0.999') // -0
parseInt('-0.999')   // -0

Running benchmarks in Chrome, the performance benefit of parseInt over Math.round is reversed if you explicitly convert to a number first:

const bench = (desc, cb) => {
    const start = new Date()

    for (let i = 0; i < 1e7; ++i) {
        cb()
    }

    const end = new Date()

    console.log(desc, `${end - start} ms`)
}

bench('parseInt',       () => parseInt('3.2', 10))       // 374 ms
bench('round coerced',  () => Math.round('3.2'))         // 738 ms
bench('round explicit', () => Math.round(Number('3.2'))) //  70 ms
bench('trunc coerced',  () => Math.trunc('3.2'))         // 671 ms
bench('trunc explicit', () => Math.trunc(Number('3.2'))) //  62 ms

Lumin • Oct 16 '21

Kudos!

Alessio Michelini • Oct 15 '21

Good to know, thanks!

lczw • Mar 14 '23

Today is finally the day I could use the information from this article. I came across a case where I had to cast a string to number. Worked flawlessly and Number() provides a nice interface to work with 👍

Andrei Dascalu • Oct 14 '21

Ok, but you did sum up the issue yourself in the examples. ParseInt will order to an integer whereas Number will get the proper numeric representation. Which means the outcome ma not be an int, which is what ParseInt guarantees .
The use of ParseInt can be replaced with Number if and only if it's accompanied by Math.round. This is not an edge case or an odd use case, it's the missing piece to have the intended outcome: an integer. The odd case is requiring the use of radix.

Alessio Michelini • Oct 14 '21

True, in fact if you want to take a string that could contain a float, and you want an integer, in that case you want to use that, but I'm not talking about that case, I'm talking about having the actual number correctly translated from a string to a number, which is probably the most common case.

Andrei Dascalu • Oct 15 '21

My point is mostly:

the performance comparison is moot because the functions discussed don't do the same thing
the correct way to formulate the use case for Number is: you should use Number when you want to extract the correct numeric value in full from a string AND you don't care about the resulting type.
use case for ParseInt: you want to ensure conversion to an integer OR the partial extraction of an integer (similar for float)

Andrei Dascalu • Oct 15 '21

The most common case for ParseInt is to get the correct number from a string with the even expectation of getting a float .... from a function that has int in the name? I hardly believe that.
I have never seen in 20 years a case of parseInt used with the expectation of getting anything except an int.

Alessio Michelini • Oct 15 '21

Unfortunately I see it using it for what Number is supposed to do, many, many times.
Btw, if you just need to get the integer (that is a positive number) from a string containing a float, then you should use double tilde operator, which does the same as Math.floor, but just 10 times faster (in Node at least), for example:

console.log(~~'3.2'); // returns 3
console.log(parseInt('3.2')); // returns 3

Mark Goho • Oct 16 '21

double tilde...🤯

Taufik Nurrohman • Oct 15 '21 • Edited

const myNumber = '1';
console.log(+myNumber);

const myNumber = '1.5';
console.log(+myNumber);

Shorter.

By the way, you will need parseInt anyway, if you want to deal with custom base number other than 10. Example is to convert HEX color code into RGB color code:

console.log([
    parseInt('ff', 16),
    parseInt('a5', 16),
    parseInt('00', 16)
]);

Augusto Peres • Jan 3

Very useful and well written post! Thank you!

coolprofessor • Oct 15 '21

What about eval()?

blackr1234 • Oct 16 '21 • Edited

It will be an overkill. There are so many working ways of parsing integers. Why bother using such a dangerous way?

hidden_dude • Oct 15 '21

eval is dangerous..

eval("alert('you are hacked')")

coolprofessor • Oct 15 '21 • Edited

I get your point, but you can already run JS commands in the console. Also, you can use str.includes("()").

blackr1234 • Oct 16 '21

However, end users being able to use console to execute any code doesn't necessarily mean that they will want to do it proactively. If you use eval and if the input is harmful, the end user may be passively affected.

coolprofessor • Oct 16 '21

Potentially, but can't you check the string for functions using 'str.includes("()")'?

blackr1234 • Oct 16 '21 • Edited

If you are referring to checking if the string contains function call by searching for "()", no it won't work because there are way too many scenarios. Consider a case when there are spaces in between the parenthesis, e.g. foo( ) and your code will then allow it to run. It will be better if you only allow whitelisted characters. However, it will still take unnecessary effort and still potentially cause the program to hang (if you are going to search/parse the whole string which can be very long). So just use the built-in functions that work just fine and don't reinvent the wheel, which is something stupid.

hidden_dude • Oct 17 '21

Don't do it.

eval() should never be used on user input.

Often parsing strings to Int is done for security reasons. Using eval() would just lead you to code injection and XSS problems.

Don't do it!

Andreas Riedmüller • Nov 25 '21

Keep in mind that both return different results when when passing nullish or boolean values:

parseInt(); // NaN
parseInt(null); // NaN
parseInt(''); // NaN
parseInt(true); // NaN

Number(); // 0
Number(null); // 0
Number(''); // 0
Number(true); // 1

Mike Becker • Jan 17 '23

This post is already a bit old, but the topic is still relevant. And the advice in this post is very much incomplete. Watch this:

Number('0x4') // 4
Number('-0x4') // NaN
Number(null) // 0
Number(undefined) // NaN
Number('') // 0
Number('  ') // 0

The Number constructor is highly unreliable when it comes to interpreting user input from a form.

Unfortunately all oneliners in Javascript are broken. Nothing works. Neither parseInt nor Number nor any other implicit or explicit attempt to convert the value.

You always have to use a combination of different functions plus some manual checking for special cases like empty string, null, or undefined... otherwise you will always experience inconsistent behavior.

Jon Randy 🎖️ • Oct 14 '21

Or use +

Alessio Michelini • Oct 14 '21

But thanks for pointing it out, I've updated the article adding the test results using the unary operator and parseFloat

Alessio Michelini • Oct 14 '21

with the unary operator is still 5/6 times slower than Number

Jon Randy 🎖️ • Oct 15 '21

Interesting - I tested on Firefox and using the unary + was almost twice as fast as Number - jsbench.me/v2kurpao3r/1

Jon Randy 🎖️ • Oct 15 '21 • Edited

The same bench on Chrome showed the two methods almost exactly the same speed - sometimes one would be faster than the other, sometimes not

Alessio Michelini • Oct 15 '21

This is interesting, I run the tests using Node (v14.17.6), in "theory" it should give you similar results to Chrome as they both use V8 as the engine, but it's clearly different

Domagoj Vidovic • Oct 18 '21

This is cool, thanks for sharing.

Btw. for measuring the performance use performance.now() instead of Date, it's more precise.

Alessio Michelini • Oct 18 '21

Thanks, forgot about that one!

n • Dec 31 '23 • Edited

I can't confirm this with my smartphone now with Android, Qualcomm's Snapdragon 665 and schedutil governor.

parseInt('3.2') and parseInt('3.2', 10) and Math.trunc(Number('3.2')) are consistently within 0,5% of each other in terms of time with stable Firefox 121.0 (20231214155439).

Only Math.trunc('3.2') is always slower by 90%-98% with Chromium 120.0.6099.144 (Official Build) (64-bit), 122.0.6215.0 (Official Build) canary (64-bit) and Firefox 121.0 (20231214155439), 123.0a1 (20231230094435).

I also noticed that Math.trunc(Number('3.2')) is 3%-5% slower with Chromium 122.0.6215.0 (Official Build) canary (64-bit). I don't know why.

Use this or something better jsbench.me/bflqt42rdh/1

Athena Ozanich • Feb 3 '22

Valid, and in the case of any kind of game development this could have a massive impact on the performance of said game.

jonosellier • Oct 17 '21

FYI, Math.round() will round the number, not chop off the decimal. Use floor or better yet |0 to drop the decimal

Jesse Phillips • Oct 16 '21

5e2[...] Number will evaluate the whole string and return the correct value 500.

Are you saying it will return an http code of 500?

Alessio Michelini • Oct 16 '21

ehm, no? :D

Jesse Phillips • Oct 17 '21

Strange, it looked like something had gone horribly wrong if you got 500 out of 1506.

I can at least see how an algorithm can utilize 5, but 500 is mind-boggling wrong.

Clément • Oct 16 '21

One thing to note that caugth me by surprise is that Number will parse any falsy value as 0, so undefined, null, false all parse fine and return 0, can be unexpected.