Benchmark: getComputedStyle - call + access variations.

HTML Preparation code:

<style type="text/css"> .ok { gap: 20px } </style>
<div class="ok"><div>one</div><div>two</div></div>

Script Preparation code:

var okThen = document.querySelector('.ok');

var alwaysGet = (function () {
   return function () {
     return window.getComputedStyle(okThen, null).columnGap || window.getComputedStyle(okThen, null).gap;
   }
})();

var mostlyGet = (function () {
   return function () {
     var got = window.getComputedStyle(okThen, null);
     return got.columnGap || got.gap;
   }
})();

var stashGet = (function () {
   var got;
   return function () {
     got = got || window.getComputedStyle(okThen, null);
     return got.columnGap || got.gap;
   }
})();

Tests:

Always compute
alwaysGet();
Mostly compute
mostlyGet();
Stash compute
stashGet();

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Always compute
Mostly compute
Stash compute

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one month ago)

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:132.0) Gecko/20100101 Firefox/132.0

Browser/OS: Firefox 132 on Mac OS X 10.15

View result in a separate tab

Test name	Executions per second
Always compute	4353609.5 Ops/sec
Mostly compute	4437836.0 Ops/sec
Stash compute	9229050.0 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated one month ago):

LLMs can make mistakes. Check important info.

The benchmark defined in the provided JSON tests different approaches to retrieving computed styles in JavaScript using the `getComputedStyle` method. Specifically, it contrasts how frequently the method is called and how its results are managed. Here's a breakdown of the test cases and what they imply:

### Test Approaches

1. **Always Compute (`alwaysGet()`)**
   - **Benchmark Definition**: Directly calls the `getComputedStyle` method every time the function is invoked, without caching the result.
   - **Execution Method**: 
     ```javascript
     return window.getComputedStyle(okThen, null).columnGap || window.getComputedStyle(okThen, null).gap;
     ```
   - **Pros**: 
     - Always retrieves the most up-to-date computed styles.
     - Useful in scenarios where styles may change dynamically and real-time values are necessary.
   - **Cons**:
     - Can be inefficient for frequent calls, leading to higher computational overhead due to repeated recalculations.

2. **Mostly Compute (`mostlyGet()`)**
   - **Benchmark Definition**: Calls `getComputedStyle` once per function invocation, caching the result in a local variable.
   - **Execution Method**:
     ```javascript
     var got = window.getComputedStyle(okThen, null);
     ```
   - **Pros**:
     - Reduces the number of times `getComputedStyle` is called, which can provide speed improvements when the values are accessed multiple times.
   - **Cons**:
     - Still recalculates styles each time the function runs, which could be a drawback if frequent updates to the styles are needed.

3. **Stash Compute (`stashGet()`)**
   - **Benchmark Definition**: Uses a closure to cache the result of `getComputedStyle` in a variable on the first call and reuses it afterward.
   - **Execution Method**:
     ```javascript
     got = got || window.getComputedStyle(okThen, null);
     ```
   - **Pros**:
     - Maximizes performance by avoiding repeated style calculations after the first call.
     - Effective in situations where the style does not change frequently and is accessed multiple times.
   - **Cons**:
     - Not suitable if the `okThen` element's styles change dynamically; any changes after the first call will not be reflected.

### Results and Performance Insights

From the latest benchmark results, the performances measured in "Executions Per Second" show the efficiency of each approach:
- **Stash Compute**: 5,790,173.5 executions per second
- **Mostly Compute**: 3,628,342.5 executions per second
- **Always Compute**: 3,573,231.5 executions per second

The clear performance winner is the **stashGet()** method, which indicates that caching the result significantly improves execution speed when the same styles are queried multiple times.

### Other Considerations

1. **Dynamic Style Changes**: When designing a system that utilizes these benchmarks, consider how frequently styles might change. If the styles are altered frequently, a method that recalculates styles (like `alwaysGet()`) might be necessary despite its inefficiency.

2. **Memory Overhead**: The `stashGet()` method retains the first computed style in memory. While this is beneficial for performance, if used inappropriately in scenarios with many changing elements, it might lead to stale or incorrect data.

### Alternatives

There are alternatives to get computed styles that may be considered depending on the user’s requirements:

- **CSS variables**: If styles are changed via CSS variables, they could be updated dynamically using JavaScript and accessed easily without needing to compute styles repeatedly.
- **Mutation Observers**: For elements where styles change frequently, mutation observers might be set up to detect changes and trigger style re-computation only when necessary.
- **Reactive Frameworks**: Utilizing libraries or frameworks (e.g., React, Vue) can abstract some of this complexity since they manage updates more efficiently through their internal mechanisms.

These alternatives can complement the approaches tested in this benchmark, depending on specific application scenarios.

Related benchmarks:

getComputedStyle - call + access variations. (version: 1)

Comparing performance of: Always compute vs Mostly compute vs Stash compute

Created: one month ago by: Guest

Jump to the latest result

Always compute

Mostly compute

Stash compute

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one month ago):