Benchmark: Number vs Unary vs parseFloat vs parseInt

Script Preparation code:

var a = []
for(let=0;i<10000;i++){
  a.push(Math.random()+'')
}

Tests:

Number
let number = a.map(Number);
Unary +
let unary = a.map((e) => +e);
parseFloat
let parse = a.map(parseFloat);
parseInt
let parse = a.map(parseInt);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Number
Unary +
parseFloat
parseInt

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one year ago)

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:138.0) Gecko/20100101 Firefox/138.0

Browser/OS: Firefox 138 on Linux

View result in a separate tab

Test name	Executions per second
Number	44995792.0 Ops/sec
Unary +	60934848.0 Ops/sec
parseFloat	73700008.0 Ops/sec
parseInt	80285200.0 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

**Benchmark Overview**

The provided JSON represents a JavaScript microbenchmark, where users can create and run tests to compare the performance of different approaches in converting strings to numbers.

**Benchmark Definition Json**

In the benchmark definition json, the script preparation code is used to generate an array `a` with 10,000 random string elements. The purpose of this initial setup is to provide a large dataset for subsequent test cases, which will convert these string elements to numbers using various methods.

The html preparation code is empty in this case, suggesting that no HTML-related code is needed or desired for this specific benchmark.

**Individual Test Cases**

There are four individual test cases:

1. **Number**: Converts the array `a` from strings to integers using the `Number()` function.
2. **Unary +**: Uses a unary plus operator (`+`) to convert the array `a` from strings to numbers.
3. **parseFloat**: Converts the array `a` from strings to floating-point numbers using the `parseFloat()` function.
4. **parseInt**: Converts the array `a` from strings to integers using the `parseInt()` function.

**Options Compared**

The four test cases compare the following options:

* Using the built-in `Number()` function
* Using a unary plus operator (`+`)
* Using `parseFloat()`
* Using `parseInt()`

These options differ in their approach to converting strings to numbers. The `Number()` function and `parseInt()` function are more explicit about their intention, while `parseFloat()` is less specific (it will return the string value if it cannot be converted to a number). The unary plus operator (`+`) is often used as a fallback or shorthand for conversion.

**Pros and Cons**

Here's a brief summary of the pros and cons of each option:

* **Number()**: Pros: explicit, efficient. Cons: may not handle edge cases (e.g., NaN).
* **Unary +**: Pros: concise, widely supported. Cons: may be slower or less efficient than `Number()` for large datasets.
* **parseFloat():** Pros: flexible, can return a float value. Cons: may return the original string if it cannot be converted to a number.
* **parseInt():** Pros: explicit, efficient. Cons: may not handle edge cases (e.g., NaN), and its behavior can vary depending on the radix.

**Library Usage**

None of the test cases explicitly use any libraries, but `parseFloat()` uses the built-in `parseFloat` function, which is a part of the ECMAScript standard.

**Special JS Features or Syntax**

The benchmark uses the following special JavaScript feature:

* The `let` declaration with block scope (introduced in ES6).
* The template literal syntax (`''`) used to concatenate strings.
* The arrow function syntax (`() =>`) for defining small, anonymous functions.

These features are widely supported and do not require any specific browser or environment configuration.

Related benchmarks:

Number vs Unary vs parseFloat vs parseInt (version: 0)

Comparing performance of: Number vs Unary + vs parseFloat vs parseInt

Created: 2 years ago by: Guest

Jump to the latest result

Number

Unary +

parseFloat

parseInt

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):