Benchmark: set.has vs. array.includes vs plain object (100 000)

Script Preparation code:

var length = 100000;
var a = Array.from({
    length
}, (e, i) => i+1);
var b = new Set(a);
var c = Object.fromEntries(a.map(e => [e, true]));
var best = 1;
var worst = length;
var middle = length / 2;

Tests:

Array.includes (best scenario)
return a.includes(best)
Set.has
return b.has(best)
Object access
return c[best]
Array.includes (middle scenario)
return a.includes(middle)
Array.includes (worst scenario)
return a.includes(worst)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Array.includes (best scenario)
Set.has
Object access
Array.includes (middle scenario)
Array.includes (worst scenario)

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/133.0.0.0 Safari/537.36

Browser/OS: Chrome 133 on Windows

View result in a separate tab

Test name	Executions per second
Array.includes (best scenario)	114573856.0 Ops/sec
Set.has	184906848.0 Ops/sec
Object access	161323600.0 Ops/sec
Array.includes (middle scenario)	200957.1 Ops/sec
Array.includes (worst scenario)	99517.2 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated 2 months ago):

LLMs can make mistakes. Check important info.

The benchmark you provided evaluates the performance of different data structures in JavaScript for checking the existence of values. The data structures being compared are:

1. **Array** (using the `.includes()` method)
2. **Set** (using the `.has()` method)
3. **Plain Object** (using property access)

### Options Compared:

1. **Array.includes()**:
   - **Best Scenario**: Checking for an element that is known to be at the beginning of the array.
   - **Middle Scenario**: Checking for an element located approximately in the middle.
   - **Worst Scenario**: Performing a check for an element that does not exist in the array or is at the end.

**Pros**:
   - Familiar and straightforward syntax.
   - Very useful for smaller arrays or cases where performance is not critical.

**Cons**:
   - Linear time complexity \(O(n)\) for searching elements as it potentially scans every element until it finds a match (or reaches the end of the array).
   - Performance degrades significantly as the size of the array increases, especially in worst-case scenarios.

2. **Set.has()**:
   - Evaluates the presence of a value in a Set.

**Pros**:
   - Uses a hash table internally, leading to average-case constant time complexity \(O(1)\) for lookups.
   - Efficient for large datasets and performs well regardless of the element's position.

**Cons**:
   - Slightly more memory overhead compared to arrays, as it stores unique values and employs a hash table.
   - Less familiar syntax for those only comfortable with arrays.

3. **Object Access**:
   - Uses a plain object and accesses a property using bracket notation.

**Pros**:
   - Average-case constant time complexity \(O(1)\) for lookups, similar to sets.
   - Very intuitive for developers who are accustomed to working with key-value pairs.

**Cons**:
   - Inherits quirks from JavaScript objects, such as prototype chain issues or collisions with property names (using strings as keys).
   - Less suitable when needing to store multiple types or complex data structures.

### Benchmark Results Summary:

The benchmark results show performance measured in executions per second for the various methods across different scenarios.

- **Object access** is the fastest among the methods tested, significantly outperforming the other two.
- **Set.has()** is the next fastest option, performing well, particularly for known values.
- **Array.includes()** has the best performance in the best-case scenario but drops dramatically in both the middle and worst cases.

### Considerations and Alternatives:

When choosing between these options, consider:

- **Use Cases**: If you need order or duplicates, Arrays might be appropriate despite their slower performance. If there's a need for fast lookups, prefer `Set` or plain Objects.
  
- **Memory Usage**: Sets and Objects will consume more memory than arrays for large datasets primarily due to their internal structure.

- **Data Manipulation**: If you’re performing a lot of insertions/deletions, `Set` and `Map` would likely show better performance over arrays due to their optimized nature for handling dynamic data.

### Other Alternatives:

- **Map**: Similar to Objects but can use any value as a key instead of just strings, providing more flexibility and avoiding key collisions.
  
- **Typed Arrays**: For specific cases where performance is critical, and you know the data type, using typed arrays (like `Int32Array`) can yield performance benefits over regular arrays.

- **Binary Search**: If dealing with sorted arrays, using binary search could give average-case performance of \(O(\log n)\). However, this requires that the data be sorted, which adds overhead when inserting/removing elements.

In conclusion, each approach has its pros and cons, and the selection depends heavily on requirements surrounding performance, memory usage, data type, and the specific problem you're trying to solve.

Related benchmarks:

set.has vs. array.includes vs plain object (100 000) (version: 1)

Comparing performance of: Array.includes (best scenario) vs Set.has vs Object access vs Array.includes (middle scenario) vs Array.includes (worst scenario)

Created: 2 months ago by: Guest

Jump to the latest result

Array.includes (best scenario)

Set.has

Object access

Array.includes (middle scenario)

Array.includes (worst scenario)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 2 months ago):