Benchmark: one intersectionObserver per one element vs one interactionObservers on many elements

HTML Preparation code:

<div id='wrapper' style="height: 300px; overflow: hidden;"></div>

Script Preparation code:

var node = document.getElementById('wrapper'), els = []

for(var i = 0; i < 30; i++) {
    var el = document.createElement('div'); el.innerText = 'hi world'; el.style['padding-bottom'] = '175px'; node.appendChild(el);
    els.push({el: el});
};

Tests:

one interactionObservers on many elements
document.getElementById('wrapper').firstChild.scrollIntoView();var interfn = function(entries){ var rel; entries.forEach(entry => { els.forEach(function(eln){ if(eln == entry.target) { rel = entry.target } }) }) rel.innerText = 'hey world'; }; var inter = new IntersectionObserver(interfn, { root: null, threshold: 0}); document.querySelectorAll('#wrapper > div').forEach(function(el){ inter.observe(el); }) var node = document.getElementById('wrapper'); node.lastChild.scrollIntoView({behavior: 'smooth'})
one intersectionObserver per one element
document.getElementById('wrapper').firstChild.scrollIntoView(); document.querySelectorAll('#wrapper > div').forEach(function(el){ var interfn = function(entry){console.log(entry[0])}; var inter = new IntersectionObserver(interfn, { root: null, threshold: 0}); inter.observe(el); }) var node = document.getElementById('wrapper'); node.lastChild.scrollIntoView({behavior: 'smooth'});

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
one interactionObservers on many elements
one intersectionObserver per one element

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 break down the benchmark and its various components.

**Benchmark Definition**
The benchmark is designed to compare two approaches:

1. **One IntersectionObserver per one element**: This approach creates an instance of `IntersectionObserver` for each individual element, observing it separately.
2. **One IntersectionObserver on many elements**: In this case, only a single instance of `IntersectionObserver` is created, which observes multiple elements at once.

**Options Compared**
The benchmark tests the performance of these two approaches:

* Creating and managing separate instances of `IntersectionObserver` for each element (one per one element)
* Creating and managing a single instance of `IntersectionObserver` to observe multiple elements simultaneously

**Pros and Cons**

1. **One IntersectionObserver per one element**:
	* Pros: Each element can be observed independently, which might be beneficial for complex scenarios or when individual elements have different observing requirements.
	* Cons: This approach creates a separate instance of `IntersectionObserver` for each element, leading to increased memory usage and potentially slower performance due to the overhead of creating multiple observers.
2. **One IntersectionObserver on many elements**:
	* Pros: Reduces memory usage and overhead associated with creating individual observers for each element. Can be beneficial when observing a large number of elements.
	* Cons: This approach requires handling all observations from multiple elements within a single observer, which might lead to increased complexity and potential performance issues if not implemented correctly.

**Library Used**
The benchmark uses the `IntersectionObserver` API, which is a modern JavaScript API for detecting changes in an element's visibility and position relative to the viewport or another element. The purpose of this API is to enable efficient and accurate detection of these changes, allowing developers to create more responsive and interactive web applications.

**Special JS Feature/Syntax**
The benchmark utilizes the `IntersectionObserver` API, which requires modern JavaScript versions (ECMAScript 2017 and later). This ensures that only browsers supporting recent versions can execute this benchmark. Other features like ES6 syntax, arrow functions (`=>`), and template literals (`\r\n`) are also used.

**Other Alternatives**

If `IntersectionObserver` is not available or supported in a particular browser, developers might consider alternative approaches:

* Using traditional event-driven programming (e.g., mouseover, mouseout) to detect visibility changes.
* Employing other libraries or frameworks that provide similar functionality, such as `react-intersection-observer` or `vue-observe-view`.
* Implementing custom logic to track element visibility and position changes.

However, the `IntersectionObserver` API is widely supported in modern browsers and has become a standard feature in web development.

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

Browser/OS: Chrome 131 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
one interactionObservers on many elements	36458.7 Ops/sec
one intersectionObserver per one element	4819.0 Ops/sec

Related benchmarks:

one intersectionObserver per one element vs one interactionObservers on many elements (version: 1)

Comparing performance of: one interactionObservers on many elements vs one intersectionObserver per one element

Created: one year ago by: Registered User

Jump to the latest result

one interactionObservers on many elements

one intersectionObserver per one element

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):