Benchmark: Closures vs Calls

Script Preparation code:

const data = [
  {a: 1, b: 10},
  {a: 2, b: 9},
  {a: 3, b: 8},
  {a: 4, b: 7},
  {a: 5, b: 6},
  {a: 6, b: 5},
  {a: 7, b: 4},
  {a: 8, b: 3},
  {a: 9, b: 2},
  {a: 10, b: 1},
]

window.fns = []

for (let c = 0; c < data.length; c++) {
  const {a, b} = data[c];
  const fn = function() {
    return `${a} + ${b} + ${c} = ${a + b + c}`
  }
  fns.push(fn)
}


class DataItem {
  a
  b

  constructor(a, b, c) {
    this.a = a
    this.b = b
  }

  calc(c) {
    return `${this.a} + ${this.b} + ${c} = ${this.a + this.b + c}`
  }
}

window.fnCalls = []

for (let c = 0; c < data.length; c++) {
  const { a, b } = data[c]
  const dataItem = new DataItem(a, b)
  fnCalls.push([dataItem.calc, dataItem, [c]])
}

Tests:

Call separate closures for each calc
fns.forEach(fn => console.log(fn()))
Call the same calc function with different arguments
fnCalls.forEach(([fn, thisArg, args] = call) => console.log(fn.apply(thisArg, args)) )

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Call separate closures for each calc
Call the same calc function with different arguments

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one year ago)

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

Browser/OS: Chrome 113 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Call separate closures for each calc	25083.4 Ops/sec
Call the same calc function with different arguments	23637.5 Ops/sec

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

LLMs can make mistakes. Check important info.

**Overview of the Benchmark**

The provided JSON represents a JavaScript microbenchmark test case on MeasureThat.net, which compares two approaches to calling functions: closures and direct calls.

**Benchmark Definition**

The benchmark definition consists of two test cases:

1. **Call separate closures for each calc**: This test case uses an array `fns` to store functions (`fn`s) that are created using a closure. Each function returns a string concatenation with the values from the `data` array and its own index (`c`). The test case then iterates over the `fns` array and calls each function using `console.log(fn())`.
2. **Call the same calc function with different arguments**: This test case uses an array `fnCalls` to store functions (`fn`s) that are created using a class-based approach. Each function returns a string concatenation with the values from the `data` array and its own index (`c`). The test case then iterates over the `fnCalls` array, applies each function to its corresponding data item and argument, and logs the result.

**Options Compared**

The two approaches compared are:

1. **Closures**: Using an array to store functions created using a closure.
2. **Direct calls**: Using a class-based approach with an array of functions that can be called directly.

**Pros and Cons of Each Approach**

**Closures:**

Pros:

* Can be more flexible and reusable, as the function is defined outside its scope.
* Can capture variables from the surrounding context.

Cons:

* May lead to increased memory usage, especially if many functions are created and stored in an array.
* Can make code harder to read and maintain due to the use of closures.

**Direct Calls:**

Pros:

* Typically leads to less memory usage, as there is no need to store function objects in an array.
* Can be more efficient, as the function can be called directly without additional overhead.

Cons:

* May lead to increased code complexity, especially when dealing with multiple functions that depend on different variables.
* Can make code harder to read and maintain due to the use of nested calls.

**Library Used**

In this benchmark, two libraries are used:

1. **`console`**: A built-in Node.js library for logging output to the console.
2. **No explicit library is mentioned**, but `Safari/537.36` indicates that the browser's rendering engine (Safari) may be involved in executing the JavaScript code.

**Special JS Features or Syntax**

There are no special JavaScript features or syntax used in this benchmark, such as ES6 classes, async/await, or Promises. The test cases rely on simple functions and basic data structures.

**Other Alternatives**

If you're interested in exploring alternative approaches to calling functions, consider:

1. **Arrow functions**: A concise way of defining small, one-time-use functions.
2. **Generator functions**: A way to define functions that can be executed as a generator, allowing for more flexibility in handling side effects and data processing.
3. **Async/await syntax**: A way to write asynchronous code that's easier to read and maintain.

Keep in mind that these alternatives may not provide the same performance benefits as closures or direct calls, depending on the specific use case and requirements.

Related benchmarks:

Closures vs Calls (version: 0)

Comparing performance of: Call separate closures for each calc vs Call the same calc function with different arguments

Created: one year ago by: Guest

Jump to the latest result

Call separate closures for each calc

Call the same calc function with different arguments

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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