Benchmark: lodash flatmap - MeasureThat.net

HTML Preparation code:

<script src="https://cdn.jsdelivr.net/lodash/4.16.0/lodash.min.js"></script>

Script Preparation code:

var x = [1,2,3]

Array.prototype.flatMap = function(f) {
  return [].concat(...this.map(f))
}

Tests:

lodash.flatMap
_.flatMap(x,x => [x-1, x, x+1])
native
x.flatMap(x => [x-1, x, x+1])

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
lodash.flatMap
native

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Safari 18 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
lodash.flatMap	16244493.0 Ops/sec
native	7460241.5 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what's being tested.

**Benchmark Overview**

The benchmark measures the performance of two approaches to implementing `flatMap` on arrays: one using Lodash, a popular JavaScript utility library, and another using the native JavaScript API.

**Lodash Implementation**

In the script preparation code, we see that an override is being made to the Array.prototype object, which is a common pattern when using libraries like Lodash. The overridden implementation of `flatMap` calls itself recursively on each element of the array, concatenating the results with `.concat()`.

```javascript
Array.prototype.flatMap = function(f) {
  return [].concat(...this.map(f));
}
```

This implementation has some pros and cons:

Pros:

* It's concise and easy to understand.
* It works by leveraging the existing `map` method on arrays, which is a native JavaScript feature.

Cons:

* The recursive call stack can lead to performance issues for large datasets.
* It modifies the Array.prototype object, which might not be desirable in certain contexts (e.g., when working with third-party libraries).

**Native Implementation**

The individual test cases define two different implementations of `flatMap` using the native JavaScript API. One implementation uses an arrow function (`x => [x-1, x, x+1]`) and another uses a traditional function declaration (`function flatMap(x) { ... }`). Both implementations use the spread operator (`...`) to concatenate the results.

```javascript
// Using arrow function
x.flatMap(x => [x-1, x, x+1])

// Using traditional function declaration
function flatMap(x) {
  return [...x.map(f => [f-1, f, f+1])].flat()
}
```

These implementations have some pros and cons:

Pros:

* They are more explicit and easier to understand than the Lodash implementation.
* The native implementation uses a stack-based approach, which is generally more efficient for large datasets.

Cons:

* The traditional function declaration implementation is less concise than the arrow function version.
* The use of `flat()` method might not be necessary in this case, as it's already an array with spread operator.

**Other Considerations**

In addition to the performance differences between these implementations, there are other factors to consider when choosing between them:

* **Code readability**: The Lodash implementation is more concise and easier to understand, but the native implementation is more explicit and arguably more readable.
* **Maintenance**: The native implementation requires more boilerplate code (e.g., function declaration), which might make it harder to maintain over time.
* **Library usage**: If you're already using Lodash in your project, the overhead of overriding Array.prototype might be negligible.

**Other Alternatives**

There are other alternatives for implementing `flatMap` on arrays, such as:

* Using a library like `ramda` or `pointfree`, which provide more functional programming-friendly implementations.
* Implementing `flatMap` using a different data structure, like a linked list, to avoid the recursive call stack.

Overall, the choice between these implementations depends on your specific use case and performance requirements. If you prioritize conciseness and ease of use, Lodash might be a good choice. However, if you need more control over the implementation or are concerned about performance, using the native JavaScript API with explicit arrow function calls might be a better option.

Related benchmarks:

lodash flatmap (version: 4)

Comparing performance of: lodash.flatMap vs native

Created: 8 years ago by: Registered User

Jump to the latest result

lodash.flatMap

native

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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