Benchmark: RegEx.test vs. String.includes vs. String.match 2

Script Preparation code:

var string = "/api/cms-content/v1/web/footer?foo=bas /api/cms-content/v1/mobile/footer?foo=bas";
var regex = /\/api\/cms-content\/v1\/web\/*|\/api\/cms-content\/v1\/mobile\/*/g;

Tests:

RegEx.test
regex.test(string);
String.includes
string.includes("/api/cms-content/v1/mobile") && string.includes("/api/cms-content/v1/web");
String.match
string.match("/api/cms-content/v1/mobile") && string.match("/api/cms-content/v1/web");

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
RegEx.test
String.includes
String.match

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) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36

Browser/OS: Chrome 132 on Linux

View result in a separate tab

Test name	Executions per second
RegEx.test	17907860.0 Ops/sec
String.includes	9542286.0 Ops/sec
String.match	1334912.6 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 benchmark and explain what's being tested, compared, and their pros and cons.

**Benchmark Overview**

The benchmark is designed to compare the performance of three different approaches for testing if a string contains certain substrings:

1. `RegEx.test()`
2. `String.includes()` with two consecutive calls
3. `String.match()` with two consecutive calls

**Library: RegExp**

The `RegExp` library is used in the first approach (`RegEx.test()`). The regular expression `/\\/api\\/cms-content\\/v1\\/web\\/*|\\/api\\/cms-content\\/v1\\/mobile\\/*/g/` is used to match substrings. In this case, it's searching for any occurrence of the pattern "/api/cms-content/v1/web/" or "/api/cms-content/v1/mobile/" within the provided string.

**String.includes()**

The second approach uses `String.includes()` twice with different substrings `/api/cms-content/v1/mobile` and `/api/cms-content/v1/web`. The idea is to test if both of these substrings exist in the same string.

**String.match()**

The third approach uses `String.match()` twice with different patterns `/api/cms-content/v1/mobile/` and `/api/cms-content/v1/web/`. Similar to `String.includes()`, it's testing for specific substrings in a single string.

**Pros and Cons of each approach:**

*   **RegEx.test():**
    *   Pros:
        *   More expressive (i.e., can be more concise)
        *   Built-in performance
    *   Cons:
        *   Can be slow if the regular expression is complex or very long
        *   Not intuitive for beginners
*   **String.includes():**
    *   Pros:
        *   Fast and efficient
        *   Easy to understand
    *   Cons:
        *   Requires two consecutive calls, which can lead to slower performance compared to RegEx.test()
        *   Might not work as expected if the substring is not contiguous
*   **String.match():**
    *   Pros:
        *   Can be used to extract matches instead of just checking for existence
        *   More flexible than `includes()`
    *   Cons:
        *   Returns an array with zero or more elements, which might require additional handling in some cases

**Special JavaScript Feature: None**

There are no special JavaScript features or syntax used beyond the regular expressions and built-in string methods.

**Alternatives:**

Some possible alternatives could be:

*   Using a library like `lodash` for utility functions, including `string.includes()`-like functionality.
*   Implementing custom search algorithms using native JavaScript data structures (e.g., searching arrays).
*   Using regular expression modifiers to optimize the performance of RegEx.test().

Related benchmarks:

RegEx.test vs. String.includes vs. String.match 2 (version: 0)

Comparing performance of: RegEx.test vs String.includes vs String.match

Created: 2 years ago by: Registered User

Jump to the latest result

RegEx.test

String.includes

String.match

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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