Benchmark: cost of eventListeners

Script Preparation code:

var audio = document.createElement("audio");

function andAOne(e){ 
  e.count = (e.count|| 0) +1; 
}

function andAOneAndAStop(e){ 
  e.count = (e.count|| 0) +1; 
  e.count === 501 && e.stopPropagationImmediately();
}

Tests:

running async 1000 event listeners
for (var i = 0; i <1000; i++) audio.addEventListener("ratechange",andAOne.bind({})); audio.playbackRate = 2;
running async 501 event listeners
for (var i = 0; i <1000; i++) audio.addEventListener("ratechange",andAOneAndAStop.bind({})); audio.playbackRate = 2;

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
running async 1000 event listeners
running async 501 event listeners

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

Browser/OS: Chrome 136 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
running async 1000 event listeners	7.2 Ops/sec
running async 501 event listeners	3.1 Ops/sec

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

LLMs can make mistakes. Check important info.

**Benchmark Overview**

The provided benchmark measures the cost of adding multiple event listeners to an HTML5 audio element. The test cases compare two scenarios: adding 1000 asynchronous event listeners and adding 501 asynchronous event listeners.

**Test Case 1: Running Async 1000 Event Listeners**

In this test case, a loop is executed 1000 times, adding an event listener for the "ratechange" event to the audio element. The event listener function `andAOne` increments a counter variable on each event trigger. The test measures the time it takes to execute this loop.

**Test Case 2: Running Async 501 Event Listeners**

Similar to Test Case 1, but with only 501 event listeners added in the loop.

**Comparison of Approaches**

The benchmark compares two approaches:

1. **Adding multiple event listeners**: This approach simulates a common web development scenario where an event listener is added for each iteration of a loop.
2. **Stopping propagation after 501 events**: In this modified version, when the counter reaches 501, the `stopPropagationImmediately` method is called on the event object, which stops the event from propagating to other listeners.

**Pros and Cons**

* **Adding multiple event listeners**: This approach has a high overhead due to the repeated addition of event listeners. Each listener needs to be registered with the browser, which can lead to increased memory usage and slower performance.
* **Stopping propagation after 501 events**: This approach reduces the overhead by stopping the event from propagating after a certain number of iterations.

Pros:

* Reduces overhead by limiting the number of event listeners
* Can lead to better performance due to reduced event processing

Cons:

* May not accurately represent real-world scenarios where events are added dynamically
* Requires careful consideration when choosing the optimal value for the stopping threshold (501 in this case)

**Library and Purpose**

The `stopPropagationImmediately` method is a native browser API that stops the propagation of an event from the current target element to all other elements in the DOM. In this benchmark, it's used to simulate a scenario where events are stopped after reaching a certain number of listeners.

**Special JS Feature or Syntax**

This benchmark does not use any special JavaScript features or syntax beyond standard ECMAScript 2015 (ES6) support. The focus is on measuring the performance impact of event listener additions rather than exploring advanced JavaScript concepts.

**Alternatives**

Other alternatives to measure the cost of adding event listeners could include:

1. **Measuring DOM manipulation**: Creating and removing elements, or manipulating element attributes, can also be used to simulate a scenario with high overhead.
2. **Simulating network requests**: Adding multiple event listeners for network request callbacks (e.g., `XMLHttpRequest` or `Fetch`) could provide insights into the performance impact of handling asynchronous events.
3. **Using a different HTML element**: Experimenting with other HTML elements, such as inputs or buttons, can also help determine the optimal approach for adding event listeners.

By exploring these alternatives, developers can gain a deeper understanding of the factors influencing event listener performance and make informed decisions when optimizing their web applications.

Related benchmarks:

cost of eventListeners (version: 0)

meassuring the cost of just calling an event listener.

Comparing performance of: running async 1000 event listeners vs running async 501 event listeners

Created: 5 years ago by: Guest

Jump to the latest result

running async 1000 event listeners

running async 501 event listeners

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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