Benchmark: filter-map vs reduce fixed

Script Preparation code:

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

Tests:

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

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
map-filter
reduce

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 141 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
map-filter	60058.3 Ops/sec
reduce	56669.4 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 Definition**

The benchmark is defined by two test cases:

1. `a.filter(filtering).map(mapping);` (Test Name: "map-filter")
2. `a.reduce(reducing,[]);` (Test Name: "reduce")

These two test cases are being compared to see which one performs better.

**Options Compared**

The options being compared are the order of operations in the two test cases:

* In the "map-filter" test case, filtering is done first and then mapping.
* In the "reduce" test case, reducing (accumulating values) happens first, followed by filtering.

**Pros and Cons of Different Approaches**

1. **Filtering-then-Mapping (Test Case: "map-filter")**:
	* Pros: This approach can take advantage of parallel processing opportunities between filtering and mapping, which might lead to better performance.
	* Cons: Filtering and mapping are sequential operations, so any filtering that fails will not be executed by the subsequent mapping step.
2. **Reducing-then-Filtering (Test Case: "reduce")**:
	* Pros: In this approach, all elements are processed before filtering occurs, ensuring that each element is evaluated at least once.
	* Cons: This approach may lead to more iterations and computations overall.

**Library Used**

None of the provided benchmark test cases use any external libraries. However, the script preparation code uses built-in JavaScript functions:

* `filter()` : Removes all elements from an array that don't match the condition specified by a function.
* `map()`: Creates a new array with the results of applying a provided function on every element in this array.
* `reduce()`: Applies a user-supplied function to each element in an array (reducing it to a single value).

**Special JS Feature or Syntax**

The script preparation code uses regular expressions (`x=>(x*114514)%1>0.5;`), but there is no special JavaScript feature or syntax being tested.

**Other Alternatives**

For benchmarking similar operations, alternatives could include:

* Using a different data structure, such as an array with `forEach()` instead of `filter()`.
* Utilizing parallel processing libraries like Web Workers to compare performance with concurrent execution.
* Replacing built-in functions with custom implementations in JavaScript (but this would likely be slower).

In conclusion, the provided benchmark compares two common JavaScript operations: filtering and mapping. The options being tested are the order of these operations, and the test cases aim to highlight any potential differences in performance between sequential vs parallel processing approaches.

Related benchmarks:

filter-map vs reduce fixed (version: 0)

modified version of `map-filter vs reduce` that switches the order of operations Original was not fair comparison as it mapped all iterations not just the ones that passed the filter

Comparing performance of: map-filter vs reduce

Created: 4 years ago by: Guest

Jump to the latest result

map-filter

reduce

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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