Benchmark: lodash flatten+ map vs reduce

HTML Preparation code:


<script src='https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.5/lodash.min.js'></script>

Script Preparation code:

var item1 = [[1,2,3], [2,4,5]]

Tests:

flatten + map
_.flatten(item1.map((item) => {return item + 5}))
reduce
item1.reduce((acc, item) => { return [...acc, item + 5] },[])

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
flatten + map
reduce

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 137 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
flatten + map	3519176.0 Ops/sec
reduce	3443711.8 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 benchmark and explain what's being tested.

**Overview**

The benchmark is designed to compare the performance of two approaches: using `lodash.flatten` with `map`, and using `reduce`. The benchmark is testing the execution speed of these two approaches on a specific input data structure, which consists of an array of arrays (`item1`) containing numbers.

**Options compared**

Two options are being compared:

1. **Lodash `flatten` + `map`**: This approach uses the `lodash.flatten` function to flatten the nested array and then maps over each element in the resulting array.
2. **Lodash `reduce`**: This approach uses the `lodash.reduce` function to iterate over the elements of the input array, applying a transformation function to each element.

**Pros and Cons**

Here are some pros and cons of each approach:

* **Lodash `flatten` + `map`**:
	+ Pros: Easy to understand and implement, as it's using two well-known functions.
	+ Cons: Creates an intermediate array with the flattened elements, which can be memory-intensive for large inputs.
* **Lodash `reduce`**:
	+ Pros: Avoids creating an intermediate array, reducing memory usage and potentially improving performance.
	+ Cons: Requires more code to set up the reduction function and can be less intuitive for some developers.

**Library**

In this benchmark, both libraries (lodash) are used. Lodash is a popular utility library that provides various functions for common tasks, such as array manipulation (`flatten`, `map`, `reduce`).

**Special JS feature or syntax**

There isn't any special JavaScript feature or syntax being tested in this benchmark. The focus is on comparing the performance of two different approaches to solve a specific problem.

**Benchmark preparation code and test cases**

The benchmark preparation code sets up an input data structure (`item1`) with nested arrays, which will be used by both `flatten` + `map` and `reduce`. Each individual test case defines a specific benchmarking scenario:

* The first test case uses `flatten` to flatten the array and then maps over each element.
* The second test case uses `reduce` to iterate over the elements of the input array, applying a transformation function.

**Other alternatives**

If you wanted to explore other approaches, some alternatives could be:

* Using a custom implementation for `flatten` or `reduce`, which might optimize performance but would require more code and expertise.
* Using a different library or framework that provides similar functions (e.g., `Array.prototype.flat()` instead of `lodash.flatten()`) to compare their performance.

Overall, this benchmark is designed to help developers evaluate the performance trade-offs between two common approaches to solving a specific problem in JavaScript.

Related benchmarks:

lodash flatten+ map vs reduce (version: 0)

Comparing performance of: flatten + map vs reduce

Created: 5 years ago by: Guest

Jump to the latest result

flatten + map

reduce

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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