Benchmark: findIndex vs indexOf vs object property

Script Preparation code:

var arr = new Array(15000);
arr.fill('')
arr = arr.map(el => Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 8));
var foo = 'erjhfdjh';
arr[7500]=foo;
var obj = arr.reduce((acc,key,i)=>{acc[key]=i;return acc},{});

Tests:

indexOf
var index = arr.indexOf(foo);
findIndex
var index = arr.findIndex(o => o===foo);
object property
var index = obj[foo]

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
indexOf
findIndex
object property

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:146.0) Gecko/20100101 Firefox/146.0

Browser/OS: Firefox 146 on Linux

View result in a separate tab

Test name	Executions per second
indexOf	16821.9 Ops/sec
findIndex	6649.0 Ops/sec
object property	765432832.0 Ops/sec

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

LLMs can make mistakes. Check important info.

I'd be happy to explain what's being tested in this JavaScript microbenchmark.

**Overview**

The benchmark is designed to compare the performance of three different approaches to find an element in an array: `indexOf`, `findIndex`, and accessing an object property directly.

**Script Preparation Code**

The script preparation code creates a large array `arr` with 15,000 elements, fills it with random strings, and sets one element to the string `'erjhfdjh'`. It also creates an object `obj` by reducing the array to a map of indices to original indices.

**Test Cases**

There are three test cases:

1. **indexOf**: Uses the `indexOf()` method to find the index of the target string `'erjhfdjh'` in the array.
2. **findIndex**: Uses the `findIndex()` method to find the index of the first element that matches the target string.
3. **object property**: Directly accesses the object property `obj[foo]`, where `foo` is the same as before.

**Options Compared**

The benchmark compares the performance of these three approaches:

* **Pro**:
	+ `indexOf`: Simple and widely supported, but may have performance issues for large arrays.
	+ `findIndex`: More precise than `indexOf`, but slower due to its more complex algorithm.
	+ Direct object property access: Fast and efficient, but limited by the object's structure.
* **Con**:
	+ `indexOf` can be slow for very large arrays or when the element is not found.
	+ `findIndex` may not work as expected if the array contains duplicate elements.

**Pros and Cons**

Here's a brief summary of each approach:

* **IndexOf**: Pros: widely supported, simple. Cons: performance issues for large arrays, may return -1 if not found.
* **FindIndex**: Pros: more precise than `indexOf`, but slower. Cons: slower, may not work with duplicate elements.
* Direct Object Property Access: Pros: fast and efficient, but limited by object structure. Cons: not applicable to all objects.

**Library Used**

The benchmark uses the built-in JavaScript array and object methods, which are part of the ECMAScript standard.

**Special JS Feature or Syntax**

There is no special feature or syntax used in this benchmark. It only relies on standard JavaScript features and methods.

**Other Alternatives**

If you need to find an element in a large array, other alternatives might include:

* Using `Array.prototype.some()` or `Array.prototype.every()`, which can be faster than `indexOf` for very large arrays.
* Implementing a custom binary search algorithm for the array.
* Using a specialized library like Lodash or Ramda.

Keep in mind that these alternatives may have trade-offs in terms of complexity, performance, and code readability.

Related benchmarks:

findIndex vs indexOf vs object property (version: 0)

Comparing performance of: indexOf vs findIndex vs object property

Created: 5 years ago by: Registered User

Jump to the latest result

indexOf

findIndex

object property

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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