Benchmark: window.getComputedStyle inline vs batched

HTML Preparation code:

<style>
    #foo {overflow-y: auto}
</style>
<div id="foo">
    <div>
        <div>
            <div>
                <div>
                    <div>
                        <div>
                            <div id="bar"></div>
                        </div>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

Script Preparation code:

var regex = /(auto|scroll)/;

function parents(node, ps) {
    if (node.parentNode === null) {
        return ps;
    }

    return parents(node.parentNode, ps.concat([node]));
};

/** batched */
function scroll_batched(element) {
    var style = window.getComputedStyle(element, null);
    return regex.test(style.getPropertyValue("overflow") + style.getPropertyValue("overflow-y") + style.getPropertyValue("overflow-x"));
}

function scrollparent_batched(element) {
    var ps = parents(element.parentNode, []);

    for (var i = 0; i < ps.length; i += 1) {
        if (scroll_batched(ps[i])) {
            return ps[i];
        }
    }
}

/** inline */

function scroll_inline(element) {
    return regex.test(window.getComputedStyle(element, null).getPropertyValue("overflow") + window.getComputedStyle(element, null).getPropertyValue("overflow-y") + window.getComputedStyle(element, null).getPropertyValue("overflow-x"));
}

function scrollparent_inline(element) {
    var ps = parents(element.parentNode, []);

    for (var i = 0; i < ps.length; i += 1) {
        if (scroll_inline(ps[i])) {
            return ps[i];
        }
    }

}

Tests:

inline getComputedStyle
var scrollparentElement = scrollparent_inline(document.getElementById("bar")); console.assert(scrollparentElement === document.getElementById("foo"), "foo should be the scroll parent, instead got %0", scrollparentElement);
batched getComputedStyle
var scrollparentElement = scrollparent_batched(document.getElementById("bar")); console.assert(scrollparentElement === document.getElementById("foo"), "foo should be the scroll parent, instead got %0", scrollparentElement);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
inline getComputedStyle
batched getComputedStyle

Fastest: N/A

Slowest: N/A

Latest run results:

No previous run results

This benchmark does not have any results yet. Be the first one to run it!

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

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and explain what's being tested, compared, and their pros and cons.

**Benchmark Description**

The benchmark measures the performance of two approaches to determine if an element is the scroll parent of another element:

1. **Batched**: This approach uses `window.getComputedStyle` with a batched query, which sends multiple requests to the browser in a single network request.
2. **Inline**: This approach also uses `window.getComputedStyle`, but without batching.

**What's being compared?**

Both approaches use the same JavaScript functions (`scroll_batched` and `scroll_inline`) to access the computed styles of an element and check if it's the scroll parent. However, they differ in how they retrieve these styles:

* **Batched**: Uses a single call to `window.getComputedStyle(element, null)` for both `overflow`, `overflow-y`, and `overflow-x` properties.
* **Inline**: Makes separate calls to `window.getComputedStyle(element, null)` for each property individually.

**Pros and Cons:**

**Batched Approach:**

Pros:

1. Reduced network overhead: By sending multiple requests in a single network request, the batched approach reduces the number of requests sent to the browser.
2. Potential performance benefit: Since the browser can process multiple requests concurrently, this approach might lead to better performance.

Cons:

1. Increased JavaScript execution time: The batched approach requires more JavaScript code to be executed, which could potentially slow down the benchmark.
2. Overhead from computing styles: If the `window.getComputedStyle` function is computationally expensive, batching can increase the overall execution time.

**Inline Approach:**

Pros:

1. Reduced JavaScript execution time: With separate calls for each property, the inline approach has less JavaScript code to execute, which might lead to faster performance.
2. Simplified code: The inline approach is more straightforward and easier to understand.

Cons:

1. Increased network overhead: By making multiple separate requests to `window.getComputedStyle`, this approach increases the number of requests sent to the browser.
2. Potential slower performance: If the browser needs to send multiple requests, this could lead to slower performance compared to the batched approach.

**Library and Special JS Features**

* **window.getComputedStyle**: This is a built-in JavaScript API that retrieves the computed styles of an element.
* No special JS features or syntax are used in this benchmark.

**Other Considerations**

The benchmark preparation code includes a recursive function `parents` to find the parent elements of a given node, which might affect the performance if not optimized properly.

**Alternatives**

If you want to explore alternative approaches, consider:

1. Using Web Workers to execute JavaScript tasks concurrently.
2. Utilizing native Web APIs like `window.getComputedStyle` with caching mechanisms.
3. Employing specialized libraries or frameworks for benchmarking and performance optimization.

Keep in mind that the choice of approach depends on your specific use case and requirements. Experimenting with different techniques can help you find the most efficient solution for your particular problem.

Related benchmarks:

window.getComputedStyle inline vs batched (version: 0)

Comparing performance of: inline getComputedStyle vs batched getComputedStyle

Created: 3 years ago by: Registered User

Jump to the latest result

inline getComputedStyle

batched getComputedStyle

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

No previous run results

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