Benchmark: match vs include

Script Preparation code:

var badWords = ['xxx',
    'vaffanculo',
    'merda',
    'cazzo',
    'figa',
    'culo',
    'dio',
    'porco',
    'porca',
    'coglione',
    'pirla',
    'deficente',
    'bastardo',
    'stronzo',
    'puttana',
    'troia',
    'frocio',
    'cacca',
    'zoccola',
    'bagascia',
    'cane',
    'madre',
    'padre',
    'porco dio',
    'procodio',
    'porca madonna',
    'madonna puttana',
    'cristo',
    'gesu',
    'berlusconi',
    'obama',
    'trump',
    'paperino',
    'pippo',
    'pluto',
    'paperone',
    'tizio',
    'caio',
    'sempronio',
    'cip',
    'ciop',
    'totti',
    'del piero',
    'ronaldo',
    'paperon',
    'paperoni',
    'disney',
    'pinco',
    'pallino',
    'zio',
    'zia',
    'ciao',
    'cane',
    'topo',
    'test',
    'prova',
    'proviamo',
    'nome',
    'cognome',]
var badWordsRegex = new RegExp(`(${badWords.map(s => `\\b${s}\\b`).join('|')})`, 'i')

Tests:

match
"cazzo".match(badWordsRegex)
include
badWords.includes("cazzo")

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
match
include

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

**Overview of the Benchmark**

The provided JSON represents a JavaScript benchmark test case on MeasureThat.net. The goal is to compare the performance of two approaches for checking if a string contains specific words: `match` and `includes`.

**What is tested?**

In this benchmark, we're testing how fast it is to check if a word (`"cazzo"`) is present in an array of bad words (`badWords`). We have two test cases:

1. **`match`**: Uses the `String.prototype.match()` method to search for the first occurrence of the word in the regular expression.
2. **`include`**: Uses the `Array.prototype.includes()` method to check if the word is present in the array.

**Options compared**

The benchmark compares two approaches:

1. `match`: Uses a regular expression with the `String.prototype.match()` method.
2. `include`: Uses an array with the `Array.prototype.includes()` method.

**Pros and Cons of each approach**

*   **`match`**:
    *   Pros:
        *   Can match multiple patterns in a single operation
        *   Can be more efficient than iterating over an array for large datasets
    *   Cons:
        *   May have higher overhead due to the creation of a regular expression object
        *   Less intuitive for simple string searches (as opposed to searching for regex patterns)
*   **`include`**:
    *   Pros:
        *   More intuitive and straightforward for simple string searches
        *   Lower overhead compared to creating a regular expression object
    *   Cons:
        *   May be less efficient than `match` for searching multiple patterns or large datasets

**Library usage**

In the provided benchmark, there are two libraries used:

*   **Regular Expressions**: Used in the `String.prototype.match()` method. The library provides a way to define complex search patterns using a syntax that's easy to read and write.
*   **Array methods**: Used in the `Array.prototype.includes()` method. This is part of the standard JavaScript API.

**Special JS features/syntax**

There are no special JS features or syntax mentioned in this benchmark, as both test cases rely on standard library functions (regex and array methods).

**Other alternatives**

Some alternative approaches to these methods could include:

*   **Using a set data structure**: Instead of using an array, you could use a `Set` data structure to store the bad words. This would allow for faster lookups with an average time complexity of O(1) compared to O(n) for arrays.
*   **Implementing a custom search function**: You could write a custom search function that uses a more efficient algorithm, such as the Knuth-Morris-Pratt (KMP) or Boyer-Moore algorithms. However, this would require additional implementation and testing.

These alternatives might offer performance benefits, but they also come with added complexity and potential trade-offs in terms of code readability and maintainability.

Keep in mind that the specific approach chosen should depend on the requirements of your use case and the characteristics of your data.

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0

Browser/OS: Firefox 110 on Mac OS X 10.15

View result in a separate tab

Test name	Executions per second
match	28168834.0 Ops/sec
include	62298868.0 Ops/sec

Related benchmarks:

match vs include (version: 0)

Comparing performance of: match vs include

Created: 2 years ago by: Guest

Jump to the latest result

match

include

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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