Benchmark: Array.every => Array.includes vs Array.every => Set.has

Script Preparation code:

var object = {
    items: Array.from({
        length: 100
    }, (_, i) => ({
        id: i,
        name: `Item-${i}`,
    }))
};

// Randomly select ~75% of items
var selectedItems = object.items
    .filter(() => Math.random() > 0.25)
    .map(item => item.id);

var set = new Set(selectedItems);

Tests:

Array.every => Array.includes
return object.items.every(({ id }) => selectedItems.includes(id));
Array.every => Set.has
return object.items.every(({ id }) => set.has(id))

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Array.every => Array.includes
Array.every => Set.has

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.every => Array.includes	46419228.0 Ops/sec
Array.every => Set.has	34525136.0 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):

LLMs can make mistakes. Check important info.

The provided benchmark tests the performance of two different approaches for checking if a set of selected item IDs exists within a collection of objects. Specifically, it compares:

1. Using `Array.prototype.includes` within `Array.prototype.every`
2. Using a `Set`'s `has` method within `Array.prototype.every`

### Benchmark Approaches

**1. `Array.every => Array.includes`:**
- **Test Definition:** The benchmark uses the `every` method on an array of objects, checking each object's `id` against the `selectedItems` array using `includes`. 
- **Pros:** 
  - The syntax is straightforward and easy to understand.
  - Good for small datasets, where performance may not be a critical factor.
- **Cons:** 
  - The `includes` method performs a linear search for every `id`, resulting in a time complexity of O(n * m) where n is the number of items in `object.items` and m is the number of `selectedItems`. This can become expensive for large datasets.

**2. `Array.every => Set.has`:**
- **Test Definition:** This approach utilizes a `Set` to store the `selectedItems`, and checks for the existence of each `id` using the `has` method while iterating through `object.items` with `every`.
- **Pros:** 
  - The `has` method on a `Set` allows for average-time complexity of O(1) for lookups, resulting in a total time complexity of O(n) for the entire operation.
  - More efficient than `includes` when dealing with larger arrays.
- **Cons:** 
  - Requires extra memory overhead to create the `Set`, which may be a consideration in memory-limited environments.
  - Slightly more complex syntax compared to the direct use of `includes`.

### Libraries and Features

- **Set:** The benchmark uses JavaScript's built-in `Set` object, which is designed for storing unique values of any type and provides efficient methods for checking existence (`has`), adding (`add`), and deleting (`delete`). Using a `Set` is considered an optimal choice when performing frequent membership checks.

### Performance Results

The benchmark results indicate a performance difference between the two approaches:
- **Array.every => Array.includes:** Approximately 46,419,228 executions per second.
- **Array.every => Set.has:** Approximately 34,525,136 executions per second.

### Considerations and Alternatives

The choice between these two methods should be dictated by context:
- For small datasets, the clarity of `includes` may be preferable, despite potential inefficiencies.
- For larger datasets or performance-critical applications, using a `Set` is usually the better option due to its O(1) lookup time.

**Alternatives:**
- Utilizing a plain loop (e.g., `for` or `forEach`) with direct comparisons could be an option, though the performance outcome may not surpass that of using `Set`.
- Other data structures or algorithms could be explored depending on the specific use case, such as binary search on sorted arrays or more sophisticated data structures like hash tables, depending on the requirements and constraints of the application.

In summary, the benchmark provides insight into performance trade-offs between readability and efficiency, emphasizing the importance of choosing the right tools based on data size and application needs.

Related benchmarks:

Array.every => Array.includes vs Array.every => Set.has (version: 2)

Comparing performance of: Array.every => Array.includes vs Array.every => Set.has

Created: one year ago by: Registered User

Jump to the latest result

Array.every => Array.includes

Array.every => Set.has

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one year ago):