Benchmark: index vs lastindexof (for right biased values)

Script Preparation code:

var a = [...Array(20000)].map((x, i) => i);
var i = 0;

Tests:

lastIndexOf (near end)
var n = a.lastIndexOf(19000 + (i++ % 1000));
indexOf (near end)
var n = a.indexOf(19000 + (i++ % 1000));
lastIndexOf (near head)
var n = a.lastIndexOf(0 + (i++ % 1000));
indexOf (near head)
var n = a.indexOf(0 + (i++ % 1000));

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
lastIndexOf (near end)
indexOf (near end)
lastIndexOf (near head)
indexOf (near head)

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15

Browser/OS: Safari 15 on Mac OS X 10.15.6

View result in a separate tab

Test name	Executions per second
lastIndexOf (near end)	2531559.5 Ops/sec
indexOf (near end)	87787.9 Ops/sec
lastIndexOf (near head)	100053.9 Ops/sec
indexOf (near head)	1508575.4 Ops/sec

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

LLMs can make mistakes. Check important info.

**Benchmark Overview**

The provided JSON represents a JavaScript microbenchmark test case on MeasureThat.net. The test aims to compare the performance of `lastIndexOf` and `indexOf` methods when searching for values near the end or start of an array.

**Script Preparation Code**

The script preparation code sets up an array `a` with 20,000 elements, where each element is a unique integer index from 0 to 19,999. The variable `i` is initialized to 0.

**Html Preparation Code**

There is no HTML preparation code provided.

**Benchmark Cases**

There are four individual test cases:

1. `lastIndexOf (near end)`: Searches for values in the array that are near the end (e.g., `19000 + (i++ % 1000)`).
2. `indexOf (near head)`: Searches for values in the array that are near the start (e.g., `0 + (i++ % 1000)`).

**Options Compared**

Two options are compared:

* `lastIndexOf`
* `indexOf`

**Pros and Cons of Each Approach**

1. **`lastIndexOf`**:
	* Pros: Can return early if the value is not found, reducing unnecessary searches.
	* Cons: May perform slower than `indexOf` for arrays with large numbers of elements near the start.
2. **`indexOf`**:
	* Pros: Generally faster than `lastIndexOf` for arrays with large numbers of elements near the start.
	* Cons: Will always search until the end of the array, potentially wasting time.

**Library and Purpose**

There is no explicit library mentioned in the benchmark definition or script preparation code. However, it's likely that a modern JavaScript engine uses its built-in `String.prototype.lastIndexOf` and `Array.prototype.indexOf` methods, which are implemented in C++ under the hood.

**Special JS Feature or Syntax**

None are explicitly used in this benchmark case. The test focuses on comparing the performance of two basic array search methods.

**Other Alternatives**

If you need to optimize array searches for specific use cases, consider the following alternatives:

* Use `Array.prototype.find` and `String.prototype.indexOf` instead of `lastIndexOf` and `indexOf`. These methods can be faster and more efficient in certain scenarios.
* Use a custom implementation that takes advantage of the array's underlying data structure, such as using binary search or hash tables.

Keep in mind that the best approach depends on the specific requirements and constraints of your project. Always profile and benchmark your code to determine the most efficient solution for your use case.

Related benchmarks:

index vs lastindexof (for right biased values) (version: 0)

Test if lastIndexOf actually performs better when the search term is expected to be near the end.

Comparing performance of: lastIndexOf (near end) vs indexOf (near end) vs lastIndexOf (near head) vs indexOf (near head)

Created: 2 years ago by: Guest

Jump to the latest result

lastIndexOf (near end)

indexOf (near end)

lastIndexOf (near head)

indexOf (near head)

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):