Benchmark: Getter / Setter vs Proxy vs Events___

Script Preparation code:

data1 = {};
handler = {
  get: (target, prop) => (target[prop]),
  set: (target, prop, value) => console.error("IMMUTABLE!!!"),
};
proxy = new  Proxy(data1, handler);
data2 = {
  get test() {
    return this._test;
  },
  set test(value) {
    return this._test = value;
  }
};
const EVENTS = new WeakMap();
function pub(object, event, data) {
  if (!EVENTS.has(object)) { return; }
  const callbacks = EVENTS.get(object)[event];
  if (callbacks) {
    for (const callback of callbacks) {
      callback(data);
    }
  }
}
function sub(object, event, callback) {
  let dict;
  if (!EVENTS.has(object)) {
    EVENTS.set(object, dict={});
  } else {
    dict = EVENTS.get(object);
  }
  let evList;
  if (event in dict) {
    (evList = dict[event]).push(callback);
  } else {
    evList = dict[event] = [callback];
  }
  return function unsub() {
    evList.splice(evList.indexOf(callback), 1);
  }
}
data3 = {};
sub(data3, 'set-test', v => data3.test = v);
sub(data3, 'get-test', () => pub(data3, 'getting-test', data3.test));
sub(data3, 'getting-test', v => a += v);
var a = 0;
data4 = {};
data5 = {};
sub(data5, 'set-test', v => { data5.test = v; pub(data5, 'getting-test', data3.test); });
sub(data5, 'getting-test', v => a += v);

Tests:

getter / setter
data2.test = Math.random(); a += data2.test;
proxy
proxy.test = Math.random(); a += proxy.test;
events
pub(data3, 'set-test', Math.random()); pub(data3, 'get-test');
plain object
data4.test = Math.random(); a += data4.test;
events (kinda cheating)
// note that is almost certainly not accurate since it probably ends after this function is called, not when getting-test triggers pub(data3, 'set-test', Math.random());

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
getter / setter
proxy
events
plain object
events (kinda cheating)

Fastest: N/A

Slowest: N/A

Latest run results:

No previous run results

This benchmark does not have any results yet. Be the first one to run it!

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

LLMs can make mistakes. Check important info.

**Benchmark Overview**

MeasureThat.net is a website that allows users to create and run JavaScript microbenchmarks. The provided JSON represents a benchmark with five test cases, each testing different approaches for updating values in an object.

**Test Cases Explanation**

1. **Getter / Setter**: This test case updates a value using the `test` property of an object (`data2`). It checks how fast the value is updated.
	* Pros: Simple and easy to understand. Tests getter and setter behavior directly.
	* Cons: May not accurately represent real-world scenarios where values are updated through more complex means (e.g., events, proxies).
2. **Proxy**: This test case updates a value using a proxy object (`proxy`). It checks how fast the value is updated when accessed through the proxy.
	* Pros: Tests proxy behavior, which can be useful in certain situations (e.g., object caching, data protection).
	* Cons: May not accurately represent real-world scenarios where values are updated through events or other means.
3. **Events**: This test case updates a value using event listeners (`pub` function). It checks how fast the value is updated when triggered by an event.
	* Pros: Tests event-driven programming, which is common in many JavaScript applications.
	* Cons: May not accurately represent real-world scenarios where values are updated through more complex means (e.g., proxies).
4. **Plain Object**: This test case updates a value using a plain object (`data4`). It checks how fast the value is updated.
	* Pros: Tests basic object behavior, which is widely used in JavaScript applications.
	* Cons: May not accurately represent real-world scenarios where values are updated through more complex means (e.g., events, proxies).
5. **Events (kinda cheating)**: This test case updates a value using the `pub` function, but with a modified implementation that bypasses some optimizations.
	* Pros: Tests the impact of certain optimizations on event-driven programming.
	* Cons: May not accurately represent real-world scenarios where values are updated through more complex means.

**Library and Syntax**

The provided JSON uses the following libraries and syntax:

* `Proxy`: built-in JavaScript Proxy API, used to create a proxy object (`proxy`).
* `WeakMap`: built-in JavaScript WeakMap data structure, used to store event listeners (`EVENTS`).
* `pub` function: custom function that broadcasts events to registered listeners.
* `sub` function: custom function that registers a listener for an event.

The JSON also uses some special syntax:

* `let dict = EVENTS.get(object)` (WeakMap lookup)
* `let evList = dict[event]` (array indexing)

**Other Considerations**

When interpreting the benchmark results, consider the following factors:

* **Device platform**: The benchmark was run on a Linux desktop with Chrome 91.
* **Browser version**: The benchmark was run in Chrome 91.
* **Execution count per second**: This value represents the number of executions performed by each test case per second.

When considering alternative approaches or optimizing these tests, keep in mind that:

* **Event-driven programming** can be more efficient than other approaches for certain use cases.
* **Proxies** can provide additional benefits (e.g., caching, data protection) but may also introduce overhead.
* **Plain object updates** are often the simplest and most straightforward way to update values, but may not always be the fastest or most efficient.

It's essential to consider these factors when deciding which approach to use in your own JavaScript applications.

Related benchmarks:

Getter / Setter vs Proxy vs Events___ (version: 0)

Comparing performance of: getter / setter vs proxy vs events vs plain object vs events (kinda cheating)

Created: 4 years ago by: Guest

Jump to the latest result

getter / setter

proxy

events

plain object

events (kinda cheating)

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

No previous run results

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