Benchmark: Array.includes vs. String.includes comparison

Tests:

Array.includes
['foo', 'bar', 'John', 'Doe'].includes('John')
String.includes
'foo bar John Doe'.includes('John')
Array.join.includes
['foo', 'bar', 'John', 'Doe'].join(',').includes('John')

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Array.includes
String.includes
Array.join.includes

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

Browser/OS: Chrome 133 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Array.includes	55444360.0 Ops/sec
String.includes	104503400.0 Ops/sec
Array.join.includes	6591631.0 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what is being tested.

**What is being tested?**

The provided benchmark compares the performance of three different approaches:

1. `Array.includes` (test case 1): Checks if an element exists in an array using the `includes` method.
2. `String.includes` (test case 2): Checks if a substring exists in a string using the `includes` method.
3. `Array.join.includes` (test case 3): Checks if a substring exists in an array after joining its elements with a separator using the `join` and `includes` methods.

**Options compared:**

The benchmark is comparing the performance of these three approaches for different inputs:

* In test case 1, the input is an array `['foo', 'bar', 'John', 'Doe']`.
* In test case 2, the input is a string `'foo bar John Doe'`.
* In test case 3, the input is an array that has been joined with commas using the `join` method.

**Pros and Cons of each approach:**

1. **Array.includes**: This approach is likely to be fast because it uses a simple iteration over the array's elements.
	* Pros: Simple and efficient implementation.
	* Cons: May not be suitable for large arrays or complex data structures.
2. **String.includes**: This approach is also relatively fast, as it can take advantage of optimized string matching algorithms.
	* Pros: Fast and optimized implementation for strings.
	* Cons: May not be suitable for large datasets or complex text processing.
3. **Array.join.includes**: This approach may seem counterintuitive, but joining an array with commas and then checking if a substring exists can actually be slower than the other two approaches.
	* Pros: None apparent.
	* Cons: May incur additional overhead due to string concatenation and searching.

**Libraries used:**

None of the test cases use any external libraries. The built-in `Array` and `String` objects are used for the tests.

**Special JS features or syntax:**

None of the test cases use any special JavaScript features or syntax that would require additional explanation.

**Other considerations:**

* The benchmark is running on a desktop platform (Mac OS X 10.15.7) with Chrome browser version 115.
* The `ExecutionsPerSecond` values indicate the number of times each approach was executed per second, which can be used to estimate performance.

**Alternatives:**

Other alternatives for implementing `includes` methods could include:

* Using a linear search algorithm (e.g., iterating over the array's elements one by one).
* Using a binary search algorithm (if the array is sorted).
* Implementing a more advanced data structure, such as a hash table or trie.
* Using a specialized library or module that optimizes string matching or array searching.

However, these alternatives are not being tested in this benchmark.

Related benchmarks:

Array.includes vs. String.includes comparison (version: 0)

Comparing performance of: Array.includes vs String.includes vs Array.join.includes

Created: 2 years ago by: Guest

Jump to the latest result

Array.includes

String.includes

Array.join.includes

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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