If we want to be consistent with parseInt, accords to this stack overflow answer, we only need to validate to return NaN when the value is null, undefined or ''.
I did a small benchmark and here's the difference between using parseInt and +:
parseInteger('10') x 95,885,668 ops/sec ±1.62% (86 runs sampled)
parseInteger('10000') x 99,261,322 ops/sec ±0.97% (91 runs sampled)
parseInteger('10000000') x 16,645,929 ops/sec ±1.75% (87 runs sampled)
parseIntegerV2('10') x 130,139,056 ops/sec ±0.92% (89 runs sampled)
parseIntegerV2('10000') x 129,740,841 ops/sec ±1.04% (91 runs sampled)
parseIntegerV2('10000000') x 129,750,977 ops/sec ±1.11% (87 runs sampled)
Fastest is parseIntegerV2('10'),parseIntegerV2('10000'),parseIntegerV2('10000000')
Also, I create a script to perform a query returning two columns (number, string) 10k times, initially the time spent is 0.43364327489994464ms, with this tiny optimization, the time down to 0.3960176892001182ms.
What do you think, do you see some edge case here?
Accords to nodejs-bench-operations,
parseInt
is significantly slower than+
operator.If we want to be consistent with
parseInt
, accords to this stack overflow answer, we only need to validate to returnNaN
when the value isnull
,undefined
or''
.I did a small benchmark and here's the difference between using
parseInt
and+
:Also, I create a script to perform a query returning two columns (number, string) 10k times, initially the time spent is
0.43364327489994464ms
, with this tiny optimization, the time down to0.3960176892001182ms
.What do you think, do you see some edge case here?