Benchmark: performance of filter + map vs reduce

Script Preparation code:

a = [];
for (i = 0; i < 1000; i++) a.push(Number(i) / 1000);

filtering = (x) => (x * 114514) % 1 > 0.5;
mapping = (x) => x + 0.1919;
reducing = (acc, x) => {
	if (filtering(x)) acc.push(mapping(x));
	return acc;
};

Tests:

reduce
a.reduce(reducing, [])
filter + map
a.filter(filtering).map(mapping);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
reduce
filter + map

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Android 14; Mobile; rv:130.0) Gecko/130.0 Firefox/130.0

Browser/OS: Firefox Mobile 130 on Android

View result in a separate tab

Test name	Executions per second
reduce	31531.0 Ops/sec
filter + map	42189.8 Ops/sec

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

LLMs can make mistakes. Check important info.

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

**Benchmark Definition**

The benchmark is designed to compare the performance of three JavaScript functions: `filter`, `map`, and `reduce`. The script preparation code generates an array of 1000 numbers, which will be used as input for these functions. Each function takes a single argument `x` and performs some operation on it.

**Options Compared**

The benchmark compares two options:

1. **Filter + Map**: This option uses the `filter` function to select elements that satisfy a condition (`x * 114514 % 1 > 0.5`) and then applies the `map` function to these selected elements, adding `0.1919` to each one.
2. **Reduce**: This option uses the `reduce` function with an accumulator (`acc`) and iterates over the array, pushing the result of applying the `mapping` function (`x + 0.1919`) to each element that satisfies the filtering condition into the accumulator.

**Pros and Cons**

* **Filter + Map**:
	+ Pros: This approach is typically more efficient than using `reduce`, as it avoids the overhead of iterating over the entire array multiple times.
	+ Cons: It requires two separate function calls, which might introduce unnecessary function overhead and create temporary variables.
* **Reduce**:
	+ Pros: Using `reduce` can be more memory-efficient, as it avoids creating intermediate arrays or objects. It also allows for a more functional programming style.
	+ Cons: The `reduce` function requires an initial accumulator value, which can lead to performance issues if the array is large.

**Library and Purpose**

None of the functions in this benchmark use any external libraries beyond the standard JavaScript library.

**Special JS Features or Syntax**

The benchmark uses a few advanced JavaScript features:

* **Arrow functions**: The `filtering`, `mapping`, and `reducing` functions are defined using arrow functions, which provide concise syntax for defining small, one-off functions.
* **Template literals**: The string interpolation in the script preparation code uses template literals (`\r\n`), which is a feature introduced in ECMAScript 2015 (ES6).

**Other Alternatives**

If you wanted to write this benchmark using alternative approaches, here are a few options:

* Use `forEach` instead of `filter` and `map`. This would eliminate the need for separate function calls, but might lead to worse performance due to the overhead of iterating over the entire array.
* Use `Array.prototype.reduce()` with a simple loop instead of relying on the built-in `reduce` function. This would add unnecessary complexity and likely reduce performance.
* Write custom loops or use a different algorithm that avoids using these functions altogether.

Keep in mind that these alternatives might not provide meaningful results, as they would likely change the behavior or introduce additional overhead.

Related benchmarks:

performance of filter + map vs reduce (version: 0)

Comparing performance of: reduce vs filter + map

Created: 3 months ago by: Guest

Jump to the latest result

reduce

filter + map

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