Benchmark: cost of HTML element 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:

2 listeners
for (var i = 0; i <2; i++) audio.addEventListener("ratechange",andAOne.bind({})); audio.playbackRate = 2;
10 listeners
for (var i = 0; i <10; i++) audio.addEventListener("ratechange",andAOne.bind({})); audio.playbackRate = 2;
50 listeners
for (var i = 0; i <50; i++) audio.addEventListener("ratechange",andAOne.bind({})); audio.playbackRate = 2;
100 listeners
for (var i = 0; i <100; i++) audio.addEventListener("ratechange",andAOne.bind({})); audio.playbackRate = 2;
200 listeners
for (var i = 0; i <200; i++) audio.addEventListener("ratechange",andAOne.bind({})); audio.playbackRate = 2;

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
2 listeners
10 listeners
50 listeners
100 listeners
200 listeners

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks and explore what's being tested in this specific benchmark.

**Benchmark Definition**

The benchmark definition provides a script that creates an HTML element, `audio`, and defines two functions: `andAOne` and `andAOneAndAStop`. The purpose of these functions is to increment a counter (`e.count`) whenever the audio element's `ratechange` event is triggered. The second function also stops the playback immediately when the count reaches 501.

**Options being compared**

In this benchmark, four different numbers of listeners are being tested: 2, 10, 50, and 100. Each test case adds an additional listener to the `ratechange` event of the audio element using the `addEventListener` method. The only difference between each test case is the number of listeners added.

**Pros and Cons of different approaches**

1. **Fewer listeners**: In the "2 listeners" test case, there are fewer events being triggered on the audio element. This might result in less overhead and faster execution times.
	* Pros: Reduced overhead, potentially faster execution times
	* Cons: May not accurately represent real-world scenarios where multiple listeners are present
2. **More listeners**: In the "100 listeners" test case, there are more events being triggered on the audio element. This could result in more CPU usage and slower execution times.
	* Pros: More realistic representation of real-world scenarios with multiple listeners
	* Cons: Increased overhead, potentially slower execution times

**Library used**

The `addEventListener` method is a part of the JavaScript DOM API, which provides a way to register event listeners for elements. This library is built into most modern browsers and does not require any additional dependencies.

**Special JS feature or syntax**

There are no special features or syntaxes being tested in this benchmark. However, it's worth noting that the use of `bind` with the arrow function (`andAOne.bind({})`) might be considered a minor optimization, as it allows for tighter closure and avoids potential issues with `this` context.

**Other alternatives**

If you wanted to modify or extend this benchmark, here are some alternative approaches:

1. **Use a different event**: Instead of using the `ratechange` event, you could use other events like `play`, `pause`, or `load`.
2. **Modify the listener function**: Change the logic inside the listener functions to perform different actions based on the event value.
3. **Increase the complexity**: Add more elements to the HTML document or introduce additional computations within the listener functions.
4. **Use a different testing framework**: If you prefer a different testing framework, such as Jest or Mocha, you could rewrite the benchmark using those frameworks' APIs.

Keep in mind that modifying the benchmark would require careful consideration of how the changes affect the results and the accuracy of the test cases.

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/119.0.0.0 Safari/537.36

Browser/OS: Chrome 119 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
2 listeners	1335.5 Ops/sec
10 listeners	113.7 Ops/sec
50 listeners	21.4 Ops/sec
100 listeners	9.9 Ops/sec
200 listeners	3.9 Ops/sec

Related benchmarks:

cost of HTML element eventListeners (version: 0)

Comparing performance of: 2 listeners vs 10 listeners vs 50 listeners vs 100 listeners vs 200 listeners

Created: one year ago by: Registered User

Jump to the latest result

2 listeners

10 listeners

50 listeners

100 listeners

200 listeners

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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