Benchmark: Array.find(false) vs for..of

Script Preparation code:

var arr = Array(1024).fill(null).map((_, i) => i);

Tests:

arr.find
arr.find((v) => v < 0);
for..of
for (var v of arr) { if (v < 0) break; }

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
arr.find
for..of

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 4 years ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36

Browser/OS: Chrome 81 on Windows

View result in a separate tab

Test name	Executions per second
arr.find	33360.2 Ops/sec
for..of	142079.7 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark definition and test cases.

**Benchmark Definition**

The benchmark measures the performance of two approaches to find an element in a sorted array:

1. `Array.prototype.find()`: This method searches for the first element in the array that satisfies the provided condition (in this case, `v < 0`). If no such element is found, it returns undefined.
2. Iterating using `for...of` loop: In this approach, we iterate over the array elements and check if any of them satisfy the condition `v < 0`. As soon as we find an element that meets the condition, we can break out of the loop.

**Options compared**

The two options are compared in terms of their execution time. The goal is to determine which approach is faster for finding a specific element in a sorted array.

**Pros and Cons**

* `Array.prototype.find()`:
	+ Pros: concise and readable syntax, can be efficient if the condition is complex.
	+ Cons: may have higher overhead due to the method call, especially for small arrays or arrays with many elements. Also, it stops iterating as soon as it finds the first matching element, which might not be what we want (in this case, we actually want to find an element that doesn't match the condition).
* Iterating using `for...of` loop:
	+ Pros: can be more control-oriented and flexible, especially when dealing with complex conditions or specific requirements.
	+ Cons: requires explicit looping, which can make the code longer and less readable. Additionally, it's less concise than the `find()` method.

**Library usage**

None in this benchmark definition.

**Special JS feature**

In this benchmark, we're using JavaScript syntax features such as arrow functions (`(v) => v < 0`), template literals (`arr = Array(1024).fill(null).map((_, i) => i)`), and the `for...of` loop. These are all standard features in modern JavaScript.

**Other alternatives**

If we were to include other approaches, some alternatives could be:

* Using `Array.prototype.reduce()` or `Array.prototype.some()` instead of `find()`
* Using a custom function with a simple linear search algorithm
* Using a different data structure, such as a binary search tree or a hash table

However, these alternatives would likely change the nature of the benchmark and might not provide a clear comparison between `find()` and the iterating approach.

**Benchmark preparation code**

The script preparation code creates an array with 1024 elements, filling it with numbers from 0 to 1023 using the `Array.prototype.fill()` method. The `map()` function is used to create an array of indices (0-1023), which is then assigned to the variable `arr`.

Related benchmarks:

Array.find(false) vs for..of (version: 0)

Benchmark unsuccessful array find against iterating using for..in. In my case this is interesting because I'm having a sorted array and know that I'm not going to successful after a certain element value is reached

Comparing performance of: arr.find vs for..of

Created: 4 years ago by: Guest

Jump to the latest result

arr.find

for..of

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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