Benchmark: isNumber: regex vs isNaN vs string comparison (version: 1) vs parseInt

HTML Preparation code:


<script src='https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.5/lodash.min.js'></script>

Script Preparation code:

window.case1 = new Proxy({}, {
    get(t, p, r) {
        if (typeof p === 'string' && !isNaN(p)) {
            return +p
        } else {
            return Reflect.get(t, p, r)
        }
    }
});
window.case2 = new Proxy({}, {
    get(t, p, r) {
        if (/^\d+$/.test(p)) {
            return +p
        } else {
            return Reflect.get(t, p, r)
        }
    }
});
window.case3 = new Proxy({}, {
    get(t, p, r) {
        if (p >= '0' && p <= '9') {
            return +p
        } else {
            return Reflect.get(t, p, r)
        }
    }
});
window.case4 = new Proxy({}, {
    get(t, p, r) {
        try {
            Number.parseInt(p);
            return +p
        } catch (_) {
            return Reflect.get(t, p, r)
        }
    }
});
window.gabage1 = 0;
window.gabage2 = 0;
window.gabage3 = 0;
window.gabage4 = 0;

Tests:

isNaN
gabage1 =+ case1[_.random(0, 1e3, false)];
regex
gabage2 =+ case2[_.random(0, 1e3, false)];
string comparison
gabage3 =+ case3[_.random(0, 1e3, false)];

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
isNaN
regex
string comparison

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's break down the provided JSON data and explain what's being tested.

**Benchmark Definition**

The benchmark is testing four different approaches to check if a value is a number:

1. `regex` (using regular expressions)
2. `isNaN` (using the built-in `isNaN` function)
3. `string comparison` (using string comparison with the `===` operator)
4. `parseInt` (using the `Number.parseInt` function)

**Benchmark Preparation Code**

The script preparation code sets up four Proxy objects (`case1`, `case2`, `case3`, and `case4`) that will be used to test each approach. Each Proxy object has a `get` method that is overridden to perform the specific check for numbers.

* `case1`: uses a simple string comparison with `+` (the unary plus operator) if the value is a string representation of a number.
* `case2`: uses a regular expression (`^\\d+$`) to match only strings that consist of one or more digits.
* `case3`: uses a string comparison with `===` if the value is within the range of '0' and '9'.
* `case4`: attempts to parse the value using `Number.parseInt`, catching any errors if it's not a valid number.

**Individual Test Cases**

Each test case is defined in an object that contains:

* `Benchmark Definition`: a JavaScript expression that assigns a value to a variable (`gabage1`, `gabage2`, or `gabage3`) using the Proxy object.
* `Test Name`: a descriptive name for the test.

The test cases are designed to exercise each of the four approaches, with random values generated using Lodash's `random` function.

**Latest Benchmark Result**

The latest benchmark result shows the performance metrics (executions per second) for each test case on Chrome 128 on a Mac OS X 10.15.7 desktop:

* `regex`: 3,245,238 executions/second
* `string comparison`: 2,275,338 executions/second
* `isNaN`: 1,793,113 executions/second

**Pros and Cons of Each Approach**

Here's a brief summary of each approach:

1. `regex`:
	* Pros: flexible and powerful for complex number validation.
	* Cons: can be slower due to regular expression parsing.
2. `isNaN`:
	* Pros: built-in function is generally fast and accurate.
	* Cons: may not work correctly with certain numeric types (e.g., NaN).
3. `string comparison`:
	* Pros: simple and straightforward for basic number validation.
	* Cons: can be slow due to string comparison, especially for larger numbers.
4. `parseInt`:
	* Pros: can handle a wide range of input formats, including strings with multiple digits.
	* Cons: may throw errors if the input is not a valid number.

**Other Considerations**

When choosing an approach, consider factors like:

* Performance requirements
* Input data distribution (e.g., mostly numeric or mixed types)
* Edge cases and error handling

Keep in mind that this benchmark is specific to JavaScript and Chrome 128. Different browsers and environments may exhibit different performance characteristics.

As for other alternatives, here are a few more approaches you might consider:

1. `Number.isInteger`: another built-in function specifically designed for integer checks.
2. `Finite` or `Infinity`: using the `Finite` or `Infinity` functions to check if a value is a finite number.
3. Custom implementation: creating your own custom function to validate numbers, taking into account specific requirements and performance trade-offs.

Feel free to ask me any follow-up questions!

Latest run results:

Run details: (Test run date: 12 days ago)

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

Browser/OS: Chrome 126 on Windows

View result in a separate tab

Test name	Executions per second
isNaN	1505940.5 Ops/sec
regex	1630874.1 Ops/sec
string comparison	1657420.6 Ops/sec

Related benchmarks:

isNumber: regex vs isNaN vs string comparison (version: 1) vs parseInt (version: 0)

Comparing performance of: isNaN vs regex vs string comparison

Created: 2 years ago by: Guest

Jump to the latest result

isNaN

regex

string comparison

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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