Benchmark: Functional Vs Imperative

Script Preparation code:

window.nums = new Array(1000).fill(0).map((x,i) => i)

Tests:

Functional
const y = nums.filter(x => x%2).map(x => x*3).filter(x => x < 100) return y
Imperative
const y = [] for(const x of nums) { if(x%2) { const x3 = x*3; if(x3 < 100) { y.push(x3) } } } return y

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Functional
Imperative

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Mobile Safari/537.36

Browser/OS: Chrome Mobile 143 on Android

View result in a separate tab

Test name	Executions per second
Functional	31940.6 Ops/sec
Imperative	293421.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 JSON and explain what is being tested, the options compared, and their pros and cons.

**Benchmark Definition**

The benchmark definition represents a JavaScript microbenchmark that compares two approaches: functional programming and imperative programming.

* **Script Preparation Code**: The script preparation code initializes an array `nums` with 1000 zeros, mapped to indices from 0 to 999. This array will be used as input for both test cases.
* **Html Preparation Code**: There is no HTML preparation code, which means that only the JavaScript code is executed.

**Individual Test Cases**

There are two test cases:

1. **Functional**
```javascript
const y = nums.filter(x => x%2).map(x => x*3).filter(x => x < 100)
return y
```
This code uses the `filter()` and `map()` array methods to transform the `nums` array in a functional programming style.

2. **Imperative**
```javascript
const y = []
for(const x of nums) {
  if(x%2) {
    const x3 = x*3;
    if(x3 < 100) {
      y.push(x3)
    }
  }
}
return y
```
This code uses a `for...of` loop and conditional statements to iterate over the `nums` array in an imperative programming style.

**Comparison of Options**

The two approaches differ in their use of array methods (`filter()` and `map()`) versus explicit loops (`for...of` and conditional statements). This comparison highlights the differences between functional and imperative programming styles.

Pros and Cons:

* **Functional Programming**
	+ Pros:
		- More concise code
		- Easier to write and maintain
		- Less prone to errors due to immutability
	+ Cons:
		- Can be less efficient due to the creation of intermediate arrays
		- May not perform as well on large datasets
* **Imperative Programming**
	+ Pros:
		- More control over the execution flow
		- Can be more efficient for large datasets
		- May be more familiar to developers with traditional programming backgrounds
	+ Cons:
		- Code can be longer and more complex
		- Prone to errors due to mutable state

**Library/Dependency**

There is no library or dependency mentioned in the benchmark definition. The tests only rely on built-in JavaScript features.

**Special JS Feature/Syntax**

None of the test cases use any special JavaScript features or syntax.

**Other Alternatives**

Other alternatives for comparing functional and imperative programming styles include:

* **Loops vs. Recursion**: Comparing traditional loops (e.g., `for`, `while`) to recursive functions.
* **Array Spreads vs. Array Concatenation**: Comparing the performance of array spreads (`[...array]`) versus concatenating arrays using the `+` operator (`array + array`).
* **Lambda Functions vs. Closures**: Comparing the performance of lambda functions (e.g., `x => x*3`) versus closures (e.g., `function multiply(x) { return x*3; }`).

These alternatives can provide additional insights into the trade-offs between different programming styles and execution strategies in JavaScript.

Related benchmarks:

Functional Vs Imperative (version: 0)

Comparing performance of: Functional vs Imperative

Created: 2 years ago by: Guest

Jump to the latest result

Functional

Imperative

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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