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});
}

Tests:

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

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
loop observable
EventTarget observable
ExtendedEvent observable

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):

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.

Latest run results:

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

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0

Browser/OS: Firefox 105 on Linux

View result in a separate tab

Test name	Executions per second
loop observable	66.0 Ops/sec
EventTarget observable	51.3 Ops/sec
ExtendedEvent observable	50.1 Ops/sec

Related benchmarks:

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

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

Created: 2 years ago by: Guest

Jump to the latest result

loop observable

EventTarget observable

ExtendedEvent observable

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 25 days ago):