Benchmark: Array.prototype.find vs _.find vs regex

HTML Preparation code:

<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.11/lodash.core.js"></script>

Script Preparation code:

var strings = [
    'one', 'two', 'three'
]
var regex = /^(one|two|three)$/;

var input = 'three'

Tests:

array find
// Native !!strings.find(function (o) { return o == input; })
_.find
!!_.find(strings, function (o) { return o==input; })
regex
regex.test(input)
regex (i)
regex.test(input)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
array find
_.find
regex
regex (i)

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what is being tested, compared, and their pros and cons.

**Benchmark Overview**

The benchmark compares three approaches to search for an element in an array:

1. **Native JavaScript Array.prototype.find()**: This method searches for an element in the array using a callback function.
2. **Lodash _.find()**: This method is part of the Lodash library, which provides a utility function for finding an element in an array.
3. **Regex pattern matching (`regex.test(input)`)**: This approach uses regular expressions to match the input string against the elements in the array.

**Options Compared**

The benchmark compares the performance of each approach:

* Native JavaScript Array.prototype.find()
* Lodash _.find()
* Regex pattern matching (`regex.test(input)`)

Each approach is executed multiple times (not shown in the provided code), and their execution rates are measured.

**Pros and Cons of Each Approach**

1. **Native JavaScript Array.prototype.find()**:
	* Pros: Efficient, built-in method, easy to use.
	* Cons: May not be optimized for performance, can be slower than other approaches for large arrays or complex search patterns.
2. **Lodash _.find()**:
	* Pros: Convenient, readable code, often used in production codebases.
	* Cons: Adds overhead due to the Lodash library, may not be as efficient as native methods.
3. **Regex pattern matching (`regex.test(input)`)**:
	* Pros: Can handle complex search patterns, flexible.
	* Cons: May be slower than native methods due to regular expression compilation and matching overhead.

**Library Used**

The benchmark uses the Lodash library for its _.find() method. Lodash is a popular utility library that provides various functional programming helpers, including array manipulation functions like _.find(). The library adds value by providing a standardized way of writing code, making it easier to read and maintain.

**Special JavaScript Feature/Syntax Used**

None mentioned in the provided benchmark code.

**Other Alternatives**

If you want to test other approaches for searching an element in an array, consider using:

* `Array.prototype.indexOf()` or `Array.prototype.findIndex()`: These methods search for an element in the array, but they return the index of the found element instead of a boolean value.
* Other libraries like jQuery, Underscore.js, or Ramda (similar to Lodash) provide similar functions for array manipulation.

The benchmark's results will help users understand which approach is fastest for their specific use case.

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36

Browser/OS: Chrome 91 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
array find	2878186.5 Ops/sec
_.find	1553211.2 Ops/sec
regex	3349807.2 Ops/sec
regex (i)	3453665.8 Ops/sec

Related benchmarks:

Array.prototype.find vs _.find vs regex (version: 0)

comparing find vs regex for search performance

Comparing performance of: array find vs _.find vs regex vs regex (i)

Created: 4 years ago by: Guest

Jump to the latest result

array find

_.find

regex

regex (i)

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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