Benchmark: Observable values

HTML Preparation code:

<div id="foo"></div>

Script Preparation code:

var element = document.getElementById("foo");

class Observed {
    constructor(onChange) {
        this._onChange = onChange;
    }

    get value() {
        return this._val;
    }

    set value(val) {
        if (this._val !== val) {
            this._val = val;
            this._onChange(this._val);
        }
    }
}

var obs = new Observed(val => {
    element.setAttribute("visibility", "hidden");
});
obs.value = 5;

var val = 5;

Tests:

Vanilla stay same
val = val; element.setAttribute("visibility", "hidden");
Vanilla change
val++; element.setAttribute("visibility", "hidden");
Observed stay same
obs.value = obs.value;
Observed change
obs.value++;

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Vanilla stay same
Vanilla change
Observed stay same
Observed change

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/605.1.15 (KHTML, like Gecko) Version/17.6.1 Safari/605.1.15

Browser/OS: Safari 17 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Vanilla stay same	12871792.0 Ops/sec
Vanilla change	12711511.0 Ops/sec
Observed stay same	509878496.0 Ops/sec
Observed change	12529439.0 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 Overview**

The benchmark measures the performance difference between two approaches: using an object with mutable properties (vanilla) versus using an observed object ( Observed class). The goal is to observe changes to a property (`val`) on a specific HTML element (`element`) without directly modifying it.

**Observed Object Library and Purpose**

The `Observed` class is not a built-in JavaScript library, but rather a custom implementation for the benchmark. It's designed to mimic an observed object that notifies its callback when a certain condition (in this case, a change in the `val` property) occurs. The purpose of this library is to decouple the observer from the observable and allow for more flexible use cases.

**Vanilla Approach**

The vanilla approach uses a plain JavaScript object with mutable properties (`var element = document.getElementById("foo"); var val = 5;`). It updates the `visibility` attribute of the HTML element using the `setAttribute()` method. This approach is straightforward but may lead to performance issues if not implemented carefully.

**Observed Approach**

The observed approach uses the custom `Observed` class, which takes a callback function as an argument. When the `val` property changes, it triggers the callback, updating the HTML element's visibility attribute. This approach provides decoupling between the observer and observable but may introduce additional overhead due to the object creation and method calls.

**Test Cases**

The test cases compare the performance of each approach under different conditions:

1. **Vanilla stay same**: The `val` property remains unchanged, so no updates occur.
2. **Vanilla change**: The `val` property is incremented (`val++`), triggering a callback update.
3. **Observed stay same**: The `obs.value` property remains unchanged, so no updates occur.
4. **Observed change**: The `obs.value` property is incremented (`obs.value++`), triggering a callback update.

**Performance Comparison**

The benchmark results show the number of executions per second for each test case on an iOS 14 device running Mobile Safari 14:

* **Vanilla stay same**: Similar performance across all runs (average ~110,000 executions/second)
* **Vanilla change**: Decreased performance compared to vanilla stay same (~70,000 executions/second)
* **Observed stay same**: Similar performance to vanilla stay same (~100,000 executions/second)
* **Observed change**: Increased overhead due to the observed object (~50,000 executions/second)

**Pros and Cons of Each Approach**

Vanilla approach:
Pros: Simple, easy to understand
Cons: May lead to performance issues if not implemented carefully

Observed approach:
Pros: Provides decoupling between observer and observable, flexible use cases
Cons: Introduces additional overhead due to object creation and method calls

**Alternatives**

Other alternatives for this benchmark could include:

* Using a library like React or Vue.js, which provide built-in observed objects (e.g., `React.createObserver` or `Vue.reactive`).
* Implementing a custom observer pattern using JavaScript's built-in methods (e.g., ` setInterval()` and `clearInterval()`).
* Using Web Workers to offload the update logic, reducing overhead on the main thread.

Keep in mind that these alternatives may affect the performance characteristics of the benchmark results.

Related benchmarks:

Observable values (version: 0)

Comparing performance of: Vanilla stay same vs Vanilla change vs Observed stay same vs Observed change

Created: 5 years ago by: Guest

Jump to the latest result

Vanilla stay same

Vanilla change

Observed stay same

Observed change

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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