Benchmark: Lazy test vs call

Script Preparation code:

function mkLazyTest(fn) {
  var thunk = fn, ran = false, value = null;
  return function() {
    if (!ran) {
      value = thunk();
      ran = true;
    }
    return value;
  };
}

function mkLazyCall(fn) {
  var thunk = fn;
  var get = function() {
    var value = thunk();
    get = function() { return value; };
    return value;
  };
  return function() { return get(); };
}

function cfn(v) { 
  return function() { return v; }
}

var fn = cfn(1);
var lz1 = mkLazyTest(fn);
var lz2 = mkLazyCall(fn);
var i = 0, iterations = 1000;

​x
 
function mkLazyTest(fn) {  var thunk = fn, ran = false, value = null;  return function() {    if (!ran) {      value = thunk();      ran = true;    }    return value;  };}​function mkLazyCall(fn) {  var thunk = fn;  var get = function() {    var value = thunk();    get = function() { return value; };    return value;  };  return function() { return get(); };}​function cfn(v) {   return function() { return v; }}​var fn = cfn(1);var lz1 = mkLazyTest(fn);var lz2 = mkLazyCall(fn);var i = 0, iterations = 1000;

Tests:

Lazy with existence test
for (i = 0; i < iterations ; i++) { lz1(); }
for (i = 0; i < iterations ; i++) {
lz1();
}
Lazy with fetch call
for (i = 0; i < iterations ; i++) { lz2(); }
for (i = 0; i < iterations ; i++) {
lz2();
}

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Experimental features:

Memory measurements supported only in Chrome.
For precise memory measurements Chrome must be launched with --enable-precise-memory-info flag.
More information: Monitoring JavaScript Memory

Test case name	Result
Lazy with existence test
Lazy with fetch call

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 8 years ago)

User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0

Browser/OS: Firefox 46 on Windows

View result in a separate tab

Test name	Executions per second
Lazy with existence test	88118.4 Ops/sec
Lazy with fetch call	89472.1 Ops/sec

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

Benchmark Overview

The provided JSON represents a JavaScript microbenchmark created on MeasureThat.net. The benchmark compares the efficiency of two lazy implementation approaches: mkLazyTest and mkLazyCall. These functions are used to create lazy implementations that replace the original function's thunk with a cached version.

Options Compared

Two options are compared:

mkLazyTest: This approach caches the result of the original function's thunk on the first call and returns the cached value for subsequent calls.
mkLazyCall: This approach creates a new get function that returns the cached value when called, and assigns this get function to itself recursively.

Pros and Cons

mkLazyTest:
- Pros: Simple implementation, easy to understand.
- Cons: May incur additional overhead due to the existence test (i.e., checking if the value has been set).
mkLazyCall:
- Pros: More efficient than mkLazyTest, as it avoids the existence test.
- Cons: Recursion-based implementation can lead to higher memory usage and potential stack overflow issues for very deep calls.

Library Usage

The provided benchmark uses a custom library (cfn) that defines a function cfn with the signature (v) -> (function()). The cfn function returns an anonymous function that always returns the original value. This function is used as the input to both mkLazyTest and mkLazyCall.

Special JavaScript Features or Syntax

None.

Other Considerations

Cache invalidation: Neither implementation accounts for cache invalidation, which can lead to stale data being returned.
Threading safety: The implementations do not consider threading safety, which is crucial in multi-threaded environments.
Overhead of function creation: Both implementations incur overhead due to the creation and invocation of new functions.

Alternatives

For similar benchmarks, you can explore other options:

mkLazyCallV2: A revised version of mkLazyCall that avoids recursion-based implementation and instead uses a simple lookup table to store cached values.
fibonacci-batch: A benchmark for measuring the performance of batch-based Fibonacci implementations, which can be optimized for different use cases (e.g., generating small vs large Fibonacci numbers).
array-parallelization: A benchmark comparing parallelization strategies for array operations, such as map(), reduce(), and filter().

These alternatives focus on specific aspects of JavaScript performance, allowing developers to compare and optimize their own implementations or explore different optimization techniques.

LLMs can make mistakes. Check important info.

**Benchmark Overview**

The provided JSON represents a JavaScript microbenchmark created on MeasureThat.net. The benchmark compares the efficiency of two lazy implementation approaches: `mkLazyTest` and `mkLazyCall`. These functions are used to create lazy implementations that replace the original function's `thunk` with a cached version.

**Options Compared**

Two options are compared:

1. **`mkLazyTest`**: This approach caches the result of the original function's `thunk` on the first call and returns the cached value for subsequent calls.
2. **`mkLazyCall`**: This approach creates a new `get` function that returns the cached value when called, and assigns this `get` function to itself recursively.

**Pros and Cons**

*   **`mkLazyTest`**:
    *   Pros: Simple implementation, easy to understand.
    *   Cons: May incur additional overhead due to the existence test (i.e., checking if the `value` has been set).
*   **`mkLazyCall`**:
    *   Pros: More efficient than `mkLazyTest`, as it avoids the existence test.
    *   Cons: Recursion-based implementation can lead to higher memory usage and potential stack overflow issues for very deep calls.

**Library Usage**

The provided benchmark uses a custom library (`cfn`) that defines a function `cfn` with the signature `(v)` -> `(function())`. The `cfn` function returns an anonymous function that always returns the original value. This function is used as the input to both `mkLazyTest` and `mkLazyCall`.

**Special JavaScript Features or Syntax**

None.

**Other Considerations**

*   **Cache invalidation**: Neither implementation accounts for cache invalidation, which can lead to stale data being returned.
*   **Threading safety**: The implementations do not consider threading safety, which is crucial in multi-threaded environments.
*   **Overhead of function creation**: Both implementations incur overhead due to the creation and invocation of new functions.

**Alternatives**

For similar benchmarks, you can explore other options:

1.  **`mkLazyCallV2`**: A revised version of `mkLazyCall` that avoids recursion-based implementation and instead uses a simple lookup table to store cached values.
2.  **`fibonacci-batch`**: A benchmark for measuring the performance of batch-based Fibonacci implementations, which can be optimized for different use cases (e.g., generating small vs large Fibonacci numbers).
3.  **`array-parallelization`**: A benchmark comparing parallelization strategies for array operations, such as map(), reduce(), and filter().

These alternatives focus on specific aspects of JavaScript performance, allowing developers to compare and optimize their own implementations or explore different optimization techniques.

Related benchmarks:

Lazy test vs call (version: 0)

Tests if a lazy implementation that uses a test vs one that replaces the thunk function is more efficient

Comparing performance of: Lazy with existence test vs Lazy with fetch call

Created: 8 years ago by: Registered User

Jump to the latest result

Lazy with existence test

Lazy with fetch call

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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