Benchmark: DOM speed - MeasureThat.net

HTML Preparation code:

<ul>
  <li>1</li>
  <li>2</li>
  <li>3</li>
  <li>2</li>
  <li>3</li>
  <li>4</li>
  <li>5</li>
  <li>6</li>
  <li>7</li>
  <li>8</li>
  <li>9</li>
</ul>

Tests:

Reselector
document.querySelectorAll( 'li', e => { document.querySelectorAll( e ).addEventListener( 'click', e => console.log( 'test' ) ); });
Direct
document.querySelectorAll( 'li', e => { e.addEventListener( 'click', e => console.log( 'test' ) ); });

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Reselector
Direct

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

**Benchmark Overview**

MeasureThat.net is a website that allows users to create and run JavaScript microbenchmarks. The benchmark in question tests the performance of two approaches for selecting elements in a DOM (Document Object Model) using the `querySelectorAll` method.

The benchmark consists of three main components:

1. **Script Preparation Code**: This section contains the code that is executed before running the benchmark. In this case, it's empty.
2. **Html Preparation Code**: This section defines the HTML structure to be used for the benchmark. The provided HTML code creates an unordered list (`<ul>`) with 10 list items (`<li>`), which will serve as the target elements for the `querySelectorAll` method.
3. **Individual Test Cases**: These are the actual tests that are run in the benchmark. Each test case has a unique name and a corresponding Benchmark Definition, which is a JavaScript code snippet.

**Options Compared**

The two options being compared in this benchmark are:

1. **Direct**: This approach uses the `querySelectorAll` method with an arrow function (`e => { ... }`) that adds an event listener to the selected elements.
2. **Reselector**: This approach uses the `querySelectorAll` method without an arrow function, and instead adds an event listener directly to the result of the `querySelectorAll` call.

**Pros and Cons**

Here are some pros and cons of each approach:

* **Direct**:
	+ Pros: May be faster due to fewer overheads, as it avoids the creation of a new array from the result of `querySelectorAll`.
	+ Cons: May cause unnecessary reselection of elements on every execution, leading to slower performance.
* **Reselector**:
	+ Pros: Avoids reselecting elements on every execution, which can improve performance by reducing DOM queries.
	+ Cons: May incur additional overhead due to the creation of a new array from the result of `querySelectorAll`.

**Library and Special JS Features**

In this benchmark, no libraries are explicitly mentioned. However, it's worth noting that some JavaScript environments may use optimizations or features like **`ECMAScript 2022 (ES2022)`** or **`CSSOM View Module (`CSSOM-VM`)```**, which could affect the performance of `querySelectorAll`.

**Other Considerations**

* **DOM Updates**: In a real-world scenario, it's possible that the DOM is updated during the execution of the benchmark. This can affect the results, as `querySelectorAll` may reselect elements on every execution.
* **Browser Optimization**: Different browsers have their own optimization techniques and caching mechanisms for `querySelectorAll`. These differences can impact the performance of each approach.

**Alternatives**

If you're interested in exploring alternative approaches or libraries for optimizing DOM queries, here are some options:

1. **QuerySelector API alternatives**: Some browsers support an alternative syntax for `querySelectorAll`, such as `querySelector` with a CSS selector. However, this may not be available in all browsers.
2. **Library-based solutions**: Libraries like jQuery or React Query provide optimized implementations of `querySelectorAll` and other DOM-related functions.
3. **DOM Patching libraries**: Libraries like React or Enzyme can be used to patch the DOM and optimize queries.

Keep in mind that each approach has its own trade-offs, and the best solution will depend on your specific use case and requirements.

Latest run results:

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

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36

Browser/OS: Chrome 103 on Windows

View result in a separate tab

Test name	Executions per second
Reselector	1344079.6 Ops/sec
Direct	1388224.6 Ops/sec

Related benchmarks:

DOM speed (version: 0)

Comparing performance of: Reselector vs Direct

Created: 2 years ago by: Guest

Jump to the latest result

Reselector

Direct

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

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