Benchmark: Observables: loops versus EventTarget vs extended event

Observables: loops versus EventTarget vs extended event (version: 0)

When the “observable” pattern is implemented in JavaScript, it's practically always done using a loop over callbacks. One problem with this approach is that an exception in one handler will crash the entire loop. You can work around this by wrapping the invocation in a try/catch block, but in doing so, you silently swallow the error. The browser provides an event dispatcher for DOM elements that runs each handler in a separate execution context, providing a better failure mode for independent listeners. `EventTarget` is an interface, so you can't directly instantiate one. But you can hijack the `EventTarget` implementation from a dummy object. This test compares multi-listener dispatches using loops and the built-in `EventTarget`. My expectation is that the native mechanism will carry some overhead, partly because of the bespoke execution context, and partly because of the extra properties instantiated on each `CustomEvent` instance. This method also has to look up events by their (string) names, rather than using direct object reference. See http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/

Comparing performance of: loop observable vs EventTarget observable vs ExtendedEvent observable

Created: 2 years ago by: Guest

Jump to the latest result

Script Preparation code:

function LoopObservable() {
	const listeners = new Set();
	this.on = fn => listeners.add(fn);
	this.off = fn => listeners.delete(fn);
	this.clear = () => listeners.clear();
	
	// This has bad failure modes.
	this.send = function(...message) {
		for (let fn of listeners)
			fn(...message);
	};
};

function EventTargetObservable() {
	// Name is arbitrary because we're using a dedicated object.  Use a shorter
	// name for shorter lookup.
	const NAME = '.';
	const __ = document.createTextNode(null);
	
	this.on = function(handler) {
		__.addEventListener(NAME, event => {
			handler(event.detail);
		});
	};
	
	this.off = function(handler) {
		__.removeEventListener(NAME, handler);
	};
	
	this.send = function(detail) {
		__.dispatchEvent(new CustomEvent(NAME, {detail}));
	};
}


class ExtendedEvent extends Event {
	constructor(name, data){
      super(name);
      this.D = data;
	}
  
  
}
function ExtendedEventTargetObservable() {
	// Name is arbitrary because we're using a dedicated object.  Use a shorter
	// name for shorter lookup.
	const NAME = '.';
	const __ = document.createTextNode(null);
	
	this.on = function(handler) {
		__.addEventListener(NAME, event => {
			handler(event.D);
		});
	};
	
	this.off = function(handler) {
		__.removeEventListener(NAME, handler);
	};
	
	this.send = function(data) {
		__.dispatchEvent(new ExtendedEvent(NAME, data));
	};
}

function run_test(observable, handlers = 2, calls = 1000) {
	for (let i = 0; i < handlers; i++)
		observable.on(message => console.log(i, message));
	
	for (let i = 0; i < calls; i++)
		observable.send({type: "hello", i});
}

​x
 
​function LoopObservable() {    const listeners = new Set();    this.on = fn => listeners.add(fn);    this.off = fn => listeners.delete(fn);    this.clear = () => listeners.clear();        // This has bad failure modes.    this.send = function(...message) {        for (let fn of listeners)            fn(...message);    };};​function EventTargetObservable() {    // Name is arbitrary because we're using a dedicated object.  Use a shorter    // name for shorter lookup.    const NAME = '.';    const __ = document.createTextNode(null);        this.on = function(handler) {        __.addEventListener(NAME, event => {            handler(event.detail);        });    };        this.off = function(handler) {        __.removeEventListener(NAME, handler);    };        this.send = function(detail) {        __.dispatchEvent(new CustomEvent(NAME, {detail}));    };}​​class ExtendedEvent extends Event {    constructor(name, data){      super(name);      this.D = data;    }    }function ExtendedEventTargetObservable() {    // Name is arbitrary because we're using a dedicated object.  Use a shorter    // name for shorter lookup.    const NAME = '.';    const __ = document.createTextNode(null);        this.on = function(handler) {        __.addEventListener(NAME, event => {            handler(event.D);        });    };        this.off = function(handler) {        __.removeEventListener(NAME, handler);    };        this.send = function(data) {        __.dispatchEvent(new ExtendedEvent(NAME, data));    };}​function run_test(observable, handlers = 2, calls = 1000) {    for (let i = 0; i < handlers; i++)        observable.on(message => console.log(i, message));        for (let i = 0; i < calls; i++)        observable.send({type: "hello", i});}​

Tests:

loop observable
run_test(new LoopObservable());
run_test(new LoopObservable());
EventTarget observable
run_test(new EventTargetObservable());
run_test(new EventTargetObservable());
ExtendedEvent observable
run_test(new ExtendedEventTargetObservable());
run_test(new ExtendedEventTargetObservable());

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
loop observable
EventTarget observable
ExtendedEvent observable

Fastest: N/A

Slowest: N/A

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Browser/OS: Chrome 131 on Windows

View result in a separate tab

Test name	Executions per second
loop observable	175.9 Ops/sec
EventTarget observable	165.0 Ops/sec
ExtendedEvent observable	177.0 Ops/sec

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

Let's break down the provided benchmark and its components.

Benchmark Overview

The benchmark, titled "Observables: loops versus EventTarget vs extended event", compares three approaches for handling observers in JavaScript:

Loops with callbacks
The native EventTarget API
An extended version of EventTarget, which wraps the original API to provide a more robust failure mode.

Loop Approach

The loop approach uses a Set to store callback functions, allowing them to be added, removed, and cleared dynamically. When an event is sent, each callback in the set is invoked with the provided message. This approach has two significant drawbacks:

Bad failure modes: If one of the callbacks throws an exception, it will crash the entire loop.
Silently swallowing errors: Wrapping the invocation in a try-catch block to catch and ignore exceptions would be needed, which silently swallows the error.

EventTarget Approach

The native EventTarget API provides a more robust failure mode than the loop approach. When an event is dispatched, each listener is executed in its own execution context, providing better isolation between listeners. However:

Overhead: The bespoke execution context and extra properties instantiated on each CustomEvent instance may introduce overhead compared to the native loop approach.
Lookup by name: Events are looked up by their string names, rather than using direct object references.

Extended EventTarget Approach

The extended version of EventTarget, ExtendedEventTargetObservable, wraps the original API to provide a more robust failure mode:

Robust failure modes: If one of the callbacks throws an exception, it will not crash the entire loop.
Explicit error handling: The extension provides explicit controls for error handling.

However, this approach also introduces additional overhead compared to the native EventTarget API.

Options Compared

The benchmark compares three options:

Loops with callbacks (bad failure modes and silently swallowing errors)
Native EventTarget API (better isolation, but possible overhead)
Extended EventTarget API (robust failure modes, explicit error handling, but additional overhead)

Pros and Cons of Each Approach

Approach	Pros	Cons
Loops with callbacks	Easy to implement, simple	Bad failure modes, silently swallowing errors
Native `EventTarget` API	Better isolation, robust	Possible overhead, lookup by name
Extended `EventTarget` API	Robust failure modes, explicit error handling	Additional overhead

Other Considerations

The benchmark does not consider the specific use case or requirements of the application.
The performance differences between the three approaches may vary depending on the specific scenario.

Alternative Approaches

While not explicitly mentioned in the benchmark, other approaches for handling observers in JavaScript include:

Using a library like RxJS (Reactive Extensions for JavaScript) that provides robust and efficient observables.
Utilizing async/await syntax to handle promises instead of callbacks.
Employing more advanced error handling mechanisms, such as try-catch blocks or error propagation.

These alternatives may offer better performance, scalability, and maintainability compared to the approaches presented in the benchmark.

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and its components.

**Benchmark Overview**

The benchmark, titled "Observables: loops versus EventTarget vs extended event", compares three approaches for handling observers in JavaScript:

1. Loops with callbacks
2. The native `EventTarget` API
3. An extended version of `EventTarget`, which wraps the original API to provide a more robust failure mode.

**Loop Approach**

The loop approach uses a `Set` to store callback functions, allowing them to be added, removed, and cleared dynamically. When an event is sent, each callback in the set is invoked with the provided message. This approach has two significant drawbacks:

* **Bad failure modes**: If one of the callbacks throws an exception, it will crash the entire loop.
* **Silently swallowing errors**: Wrapping the invocation in a try-catch block to catch and ignore exceptions would be needed, which silently swallows the error.

**EventTarget Approach**

The native `EventTarget` API provides a more robust failure mode than the loop approach. When an event is dispatched, each listener is executed in its own execution context, providing better isolation between listeners. However:

* **Overhead**: The bespoke execution context and extra properties instantiated on each `CustomEvent` instance may introduce overhead compared to the native loop approach.
* **Lookup by name**: Events are looked up by their string names, rather than using direct object references.

**Extended EventTarget Approach**

The extended version of `EventTarget`, `ExtendedEventTargetObservable`, wraps the original API to provide a more robust failure mode:

* **Robust failure modes**: If one of the callbacks throws an exception, it will not crash the entire loop.
* **Explicit error handling**: The extension provides explicit controls for error handling.

However, this approach also introduces additional overhead compared to the native `EventTarget` API.

**Options Compared**

The benchmark compares three options:

1. Loops with callbacks (bad failure modes and silently swallowing errors)
2. Native `EventTarget` API (better isolation, but possible overhead)
3. Extended `EventTarget` API (robust failure modes, explicit error handling, but additional overhead)

**Pros and Cons of Each Approach**

| Approach | Pros | Cons |
| --- | --- | --- |
| Loops with callbacks | Easy to implement, simple | Bad failure modes, silently swallowing errors |
| Native `EventTarget` API | Better isolation, robust | Possible overhead, lookup by name |
| Extended `EventTarget` API | Robust failure modes, explicit error handling | Additional overhead |

**Other Considerations**

* The benchmark does not consider the specific use case or requirements of the application.
* The performance differences between the three approaches may vary depending on the specific scenario.

**Alternative Approaches**

While not explicitly mentioned in the benchmark, other approaches for handling observers in JavaScript include:

1. Using a library like RxJS (Reactive Extensions for JavaScript) that provides robust and efficient observables.
2. Utilizing async/await syntax to handle promises instead of callbacks.
3. Employing more advanced error handling mechanisms, such as try-catch blocks or error propagation.

These alternatives may offer better performance, scalability, and maintainability compared to the approaches presented in the benchmark.

Related benchmarks: