Benchmark: findIndex vs find vs map and indexOf - JavaScript performance

Script Preparation code:

var arr = Array.from({
    length: 1000
}, (_, i) => {
    return {
        id: i,
    };
});
var foo = Math.floor(Math.random() * 1000);

Tests:

findIndex
const index = arr.findIndex((num) => num.id === foo);
find
const value = arr.find((num) => num.id === foo);
map and indexOf
const index = arr.map((num) => num.id).indexOf(foo);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
findIndex
find
map and indexOf

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

**Overview of the Benchmark**

The provided JSON represents a JavaScript microbenchmarking test case, where three different approaches are compared: `findIndex`, `find`, and `map` followed by `indexOf`. The benchmark aims to measure the performance of each approach in finding an element with a specific id in an array.

**Options Compared**

1. **`findIndex`**: This method returns the index of the first element in the array that satisfies the provided condition.
2. **`find`**: This method returns the value of the first element in the array that satisfies the provided condition.
3. **`map` + `indexOf`**: This approach first maps the array to extract the id values and then uses `indexOf` to find the index of the target id.

**Pros and Cons of Each Approach**

1. **`findIndex`**:
	* Pros: Efficient use of memory, as it only requires a single pass through the array.
	* Cons: May not be suitable for large arrays with many elements, as it uses more CPU cycles to iterate and check each element.
2. **`find`**:
	* Pros: Simple and easy to understand, but may be less efficient than `findIndex` due to the additional overhead of creating an intermediate object.
	* Cons: Requires creating a new object, which can consume memory and slow down the performance for large arrays.
3. **`map` + `indexOf`**:
	* Pros: Can be more efficient than using `find` or `findIndex`, as it reduces the number of iterations over the array by mapping it first.
	* Cons: Requires creating an intermediate array, which can consume memory and slow down the performance for large arrays. Additionally, `indexOf` may have a higher overhead due to its search algorithm.

**Library Usage**

None of the benchmarking approaches rely on any external libraries.

**Special JS Features/Syntax**

None mentioned in the provided JSON.

**Other Considerations**

* The use of `Array.from()` to create the array can impact performance, especially for large arrays.
* The randomization of the target id (`foo`) adds a layer of complexity and variability to the benchmarking results.

**Alternatives**

If you want to explore alternative approaches or libraries for this benchmark, some options could be:

1. Using `Array.prototype.some()` instead of `findIndex` or `find`.
2. Implementing a custom search algorithm using bitwise operations or caching.
3. Utilizing modern JavaScript features like `Set` or `Map` to improve performance.
4. Using libraries like Microbenchmark.js, Benchmark.js, or PerfBench to measure performance.

Keep in mind that the choice of alternative approaches will depend on your specific requirements and goals for this benchmarking test case.

Latest run results:

Run details: (Test run date: 9 months ago)

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

Browser/OS: Chrome 121 on Windows

View result in a separate tab

Test name	Executions per second
findIndex	24963.8 Ops/sec
find	26384.7 Ops/sec
map and indexOf	274176.4 Ops/sec

Related benchmarks:

findIndex vs find vs map and indexOf - JavaScript performance (version: 0)

Comparing performance of: findIndex vs find vs map and indexOf

Created: one year ago by: Guest

Jump to the latest result

findIndex

find

map and indexOf

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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