Benchmark: eval vs parseInt vs Number

Tests:

long eval()
eval("99999999999999999999999999999999999999999999999999999999999999999999999999");
long parseInt()
parseInt("99999999999999999999999999999999999999999999999999999999999999999999999999");
short eval()
eval("999");
short parseInt()
parseInt("999");
Number class call
Number('999');

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
long eval()
long parseInt()
short eval()
short parseInt()
Number class call

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 3 years ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

Browser/OS: Chrome 92 on Windows

View result in a separate tab

Test name	Executions per second
long eval()	2781055.2 Ops/sec
long parseInt()	3323568.2 Ops/sec
short eval()	2844090.8 Ops/sec
short parseInt()	7718126.0 Ops/sec
Number class call	7849054.5 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's break down what's being tested in the provided JSON.

**Benchmark Definition**: The benchmark is defined by a single JavaScript function that performs no operation, but rather serves as a placeholder to test the performance of different operations: `eval`, `parseInt`, and the built-in `Number` constructor. The idea is to compare how fast each operation can be performed on large numbers.

**Options being compared**:

1. **`eval`**: Evaluates a JavaScript expression by parsing it and executing it.
2. **`parseInt`**: Converts a string number (with optional radix) to an integer value.
3. **`Number`**: Creates a new number from the given string or performs a conversion on the existing value.

**Pros and Cons of each approach**:

1. **`eval`**:
	* Pros: Can handle arbitrary JavaScript expressions, allows for more complex operations.
	* Cons: Performance is typically slower than other options due to the overhead of parsing and executing JavaScript code. It's also a security risk if used with untrusted input.
2. **`parseInt`**:
	* Pros: Fast and efficient for simple number conversions. Can handle radix values to convert strings from different bases (e.g., hexadecimal).
	* Cons: Limited in its capabilities, only designed for converting strings to integers. May not work as expected if the input string is not a valid number.
3. **`Number`**:
	* Pros: Simple and efficient way to create numbers from strings or perform conversions. Fast and widely supported across browsers.
	* Cons: Only works with numeric strings or existing numbers; cannot handle non-numeric values.

**Library usage**: None of the benchmarked functions use any external libraries beyond built-in JavaScript functionality.

**Special JS features/syntax**: The benchmarks utilize:

1. **`eval`**: Used for parsing and executing arbitrary JavaScript expressions.
2. **Radix conversions**: `parseInt` is used to demonstrate its ability to convert strings from different bases (e.g., hexadecimal).

**Other alternatives**:

If you were to rewrite this benchmark using alternative approaches, you might consider:

1. **Using a library like numjs** or **mathjs** for numerical computations, which could provide more efficient and accurate results.
2. **Utilizing `Atomics` or `SharedArrayBuffer`** for large number operations, as they offer improved performance for certain types of calculations.

However, keep in mind that these alternatives might not directly compare to the original benchmarking use cases, so it's essential to carefully evaluate their applicability and accuracy.

Related benchmarks:

eval vs parseInt vs Number (version: 0)

Comparing performance of: long eval() vs long parseInt() vs short eval() vs short parseInt() vs Number class call

Created: 3 years ago by: Guest

Jump to the latest result

long eval()

long parseInt()

short eval()

short parseInt()

Number class call

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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