Benchmark: flatMap() vs filter().map()

Script Preparation code:

var arr = [];
var i = 0;

while (i <= 1E5) arr[i] = i++;

Tests:

filter().map()
arr.filter(x => x % 3).map(x => x/100)
flatMap()
arr.flatMap(x => x % 3 ? x/100 : [])

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
filter().map()
flatMap()

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

Browser/OS: Firefox 138 on Mac OS X 10.15

View result in a separate tab

Test name	Executions per second
filter().map()	850.2 Ops/sec
flatMap()	802.9 Ops/sec

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

LLMs can make mistakes. Check important info.

Let's dive into explaining the benchmark.

**Benchmark Definition**

The provided JSON represents a JavaScript microbenchmark that compares two approaches: `flatMap()` and `filter().map()`. The benchmark is designed to measure the performance difference between these two methods when used in conjunction with each other.

**Options Compared**

The benchmark compares the execution time of the following options:

1. `arr.flatMap(x => x % 3 ? x/100 : [])`
2. `arr.filter(x => x % 3).map(x => x/100)`

Both approaches are designed to iterate over an array (`arr`) and perform a calculation on each element. The main difference lies in how the iteration is handled:

* `flatMap()` returns a new array with the results of applying the provided function to each element, without creating an intermediate array.
* `filter().map()` creates two intermediate arrays: one filtered by `filter()`, and then mapped over the result using `map()`.

**Pros and Cons**

Here's a brief summary of the pros and cons of each approach:

1. `flatMap()`
	* Pros:
		+ Creates fewer intermediate arrays, potentially reducing memory allocation and garbage collection overhead.
		+ Can be more efficient for large datasets, as it avoids creating unnecessary arrays.
	* Cons:
		+ May require a slightly higher number of function calls, which can lead to increased execution time due to the overhead of invoking functions.
2. `filter().map()`
	* Pros:
		+ Can be easier to understand and maintain, as the intent is clearer (filtering and then mapping).
	* Cons:
		+ Creates two intermediate arrays, which can increase memory allocation and garbage collection overhead.

**Library/Functionality Used**

In this benchmark, no specific library or functionality is used beyond the built-in JavaScript methods `flatMap()` and `filter().map()`. However, it's worth noting that some browsers may have additional optimizations for these methods, such as Chrome's `flatMap()` optimization (introduced in version 129).

**Special JS Feature/Syntax**

The benchmark uses no special JavaScript features or syntax beyond the standard ECMAScript methods mentioned earlier.

**Other Alternatives**

For those interested in exploring alternative approaches:

1. **Array.prototype.reduce()**: Instead of using `filter().map()`, you could use `reduce()` to combine the elements and calculate the result.
2. **Closures**: You could create a closure that iterates over the array, performing the calculation on each element without creating intermediate arrays.
3. **Loop-based iteration**: You could write a simple loop to iterate over the array, performing the calculation on each element manually.

Keep in mind that these alternatives may not be as concise or readable as using built-in methods like `flatMap()` and `filter().map()`, but they can provide an interesting perspective on how to solve similar problems.

Related benchmarks:

flatMap() vs filter().map() (version: 0)

flatMap vs filter map

Comparing performance of: filter().map() vs flatMap()

Created: 4 years ago by: Guest

Jump to the latest result

filter().map()

flatMap()

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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