Benchmark: isNumber: regex vs isNaN

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.gabage1 = 0;
window.gabage2 = 0;

Tests:

isNaN
for (let i = 0; i < 1e6;i++) { gabage1 =+ case1[i]; }
regex
for (let i = 0; i < 1e6;i++) { gabage2 += case2[i]; }

Historical Performance Data aggregated from 16 community runs

Desktop Results:

Chrome 16 runs

isNaN

4/s

regex

3/s

Fastest: isNaN (1.1x faster)

View exact numbers

✓ isNaN: 4 ops/sec
• regex: 3 ops/sec

Results show median performance across all community submissions. Run this benchmark yourself to verify on your device.

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
isNaN
regex

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 2 months ago)

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

Browser/OS: Chrome 149 on Windows

View result in a separate tab

isNaN

4/s

regex

3/s

View exact numbers

Test name	Executions per second
✓ isNaN	4 Ops/sec
regex	3 Ops/sec

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

LLMs can make mistakes. Check important info.

I'll break down the provided benchmark definition and test cases to explain what's being tested, compared, and considered.

**Benchmark Definition JSON**

The `Name` field indicates that this benchmark is called "isNumber: regex vs isNaN". The `Description` explains that it judges an object property key as a number. Let's dive into the script preparation code:

*   `window.case1 = new Proxy({}, { ... });`: Creates a proxy object (`case1`) with a getter function for each property. This getter checks if the property is a string and can be parsed to an integer using `isNaN`. If true, it returns the parsed value; otherwise, it returns the original value.
*   `window.case2 = new Proxy({}, { ... });`: Similar to `case1`, but uses a regular expression (`/^\\d+$/`) to check if the property is a number. The regex pattern `/^\\d+$/` matches one or more digits (`\\d+`) at the start of the string (`^`). If true, it returns the parsed value; otherwise, it returns the original value.
*   `window.gabage1 = 0;` and `window.gabage2 = 0`: These variables are initialized to zero, likely for initialization purposes.

The `Html Preparation Code` field is empty in this case.

**Individual Test Cases**

There are two test cases:

*   **Test Name: "isNaN"**
    *   Benchmark Definition: `for (let i = 0; i < 1e6;i++) { gabage1 =+ case1[i]; }`
    *   This test iterates over a million iterations and assigns the value of each property (`case1[i]`) to `gabage1`. The intention is to measure how many times NaN (Not a Number) is returned when trying to access properties with non-numeric values.
*   **Test Name: "regex"**
    *   Benchmark Definition: `for (let i = 0; i < 1e6;i++) { gabage2 += case2[i]; }`
    *   Similar to the previous test, but uses regular expression (`^\\d+$`) to check if properties are numbers. The intention is to measure how many times a number is returned when trying to access properties with numeric values.

**Pros and Cons of Each Approach**

*   **Proxy-based approach (case1)**:
    *   Pros:
        *   More efficient, as it avoids the overhead of function calls.
        *   Can be optimized further using techniques like caching or memoization.
    *   Cons:
        *   May be less readable due to the use of Proxies and getter functions.
*   **Regular expression-based approach (case2)**:
    *   Pros:
        *   More readable, as it uses a well-known pattern (`^\\d+$`) for validation.
        *   Can be easily understood by developers familiar with regex patterns.
    *   Cons:
        *   May be less efficient due to the overhead of regular expression processing.

**Other Considerations**

*   **Performance**: The benchmark measures performance, so it's essential to consider how each approach affects execution speed. In this case, the proxy-based approach is likely faster due to its efficiency.
*   **Readability and Maintainability**: While readability is not as critical in a performance-focused benchmark, understanding the code is still important for developers. The regular expression-based approach may be more readable and maintainable.

**Alternative Approaches**

Other alternatives could include:

*   Using JavaScript's built-in `Number()` function instead of Proxies or regex patterns.
*   Implementing a custom parser to handle numeric values in a specific way (e.g., allowing decimal points).
*   Comparing different validation methods, such as using a library like `lodash` to perform validation.

However, these alternatives might not provide a direct comparison to the existing approaches and may add unnecessary complexity.

isNumber: regex vs isNaN (version: 0) Benchmark.js

judge an object property key is a number

Comparing performance of: `isNaN vs regex`

Created: 7 years ago by: Guest

Go to the latest result

isNaN

regex

Historical Performance Data aggregated from 16 community runs

Desktop Results:

Chrome 16 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

isNumber: regex vs isNaN (version: 0) Benchmark.js

judge an object property key is a number

Comparing performance of: isNaN vs regex

Created: 7 years ago by: Guest

Go to the latest result

isNaN

regex

Historical Performance Data aggregated from 16 community runs

Desktop Results:

Chrome 16 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

Related benchmarks

Comparing performance of: `isNaN vs regex`