Benchmark: Observables: loops with try/catch versus EventTarget

Observables: loops with try/catch versus EventTarget (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

Created: one year 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) {
            try {
                fn(...message);
            } catch (error) {
                console.error(error);
            }
        }
    };
};

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
        }));
    };
}

function run_test(observable, handlers = 5, 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());

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
loop observable
EventTarget 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 what's being tested on the provided JSON and explain the options, pros, cons, and other considerations.

**Overview**

The benchmark compares two approaches for implementing the "observable" pattern in JavaScript:

1. **Loop-based approach**: using a loop over callbacks to handle events.
2. **EventTarget-based approach**: hijacking the `EventTarget` interface from a dummy object to dispatch events.

**Options being compared**

In both cases, the test creates an observable object with methods to add and remove event handlers (`on` and `off`) and send events (`send`). The main difference lies in how these methods are implemented:

1. **Loop-based approach**: uses a loop over callbacks to iterate through the list of handlers.
2. **EventTarget-based approach**: creates a custom `EventTarget` object with an `addEventListener` method that registers event listeners.

**Pros and Cons**

1. **Loop-based approach**
	* Pros:
		+ Simple to implement
		+ Direct access to event handlers (no indirection)
	* Cons:
		+ Bad failure modes: if one handler throws an error, it will crash the entire loop.
		+ Silently swallows errors (no error propagation).
2. **EventTarget-based approach**
	* Pros:
		+ Better failure modes: if one listener throws an error, it won't affect other listeners.
		+ Error propagation is handled by the `EventListener` mechanism.
	* Cons:
		+ More complex implementation
		+ Requires creating a custom `EventTarget` object.

**Library and purpose**

In this benchmark, the `EventTarget` library is used to create an observable object that can dispatch events. The `EventTarget` interface is a standard part of the DOM API in web browsers, providing a way to attach event listeners to objects.

The custom `EventTargetObservable` class is created to hijack this interface and provide a more robust implementation for the observable pattern.

**Special JS feature or syntax**

In this benchmark, no special JavaScript features or syntax are used beyond standard ES6 syntax.

**Other alternatives**

If not using an `EventTarget`-based approach, other alternatives could include:

1. Using a library like RxJS (Reactive Extensions for JavaScript) to create observables.
2. Implementing the observable pattern manually without using an event dispatching mechanism.

However, these alternatives may introduce additional complexity and dependencies, making them less suitable for this benchmark.

Keep in mind that the choice of approach depends on the specific use case and requirements of the observable pattern implementation.

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/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

Browser/OS: Chrome 116 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
loop observable	10.7 Ops/sec
EventTarget observable	12.1 Ops/sec

Related benchmarks: