Toggle navigation
MeasureThat
.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
window.getComputedStyle vs. memoized version
(version: 0)
Comparing performance of:
getComputedStyle vs memoized getComputedStyle
Created:
4 years ago
by:
Guest
Go to the latest result
HTML Preparation code:
<div id="foo"></div>
Tests:
getComputedStyle
var ele = document.getElementById('foo'); var i = 3000; while (i--) { chekele(); } function chekele() { return window.getComputedStyle(ele, null).getPropertyValue("display").indexOf('none') === -1; }
memoized getComputedStyle
var ele = document.getElementById('foo'); var computedStyle = window.getComputedStyle(ele, null); var i = 3000; while (i--) { chekele(); } function chekele() { return computedStyle.getPropertyValue("display").indexOf('none') === -1; }
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (2)
Previous results
Fork
Test case name
Result
getComputedStyle
memoized getComputedStyle
Fastest:
N/A
Slowest:
N/A
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/129.0.0.0 Safari/537.36
Browser/OS:
Chrome 129 on Mac OS X 10.15.7
View result in a separate tab
Embed
Embed Benchmark Result
<iframe src="https://measurethat.net/Embed?id=556036" width="100%" height="500px"></iframe>
memoized getComputedStyle
3K/s
getComputedStyle
1K/s
View exact numbers
Test name
Executions per second
✓
memoized getComputedStyle
3,209 Ops/sec
getComputedStyle
1,095 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
**Benchmark Overview** The provided benchmark tests the performance difference between using `window.getComputedStyle` directly and a memoized version of this function in JavaScript. **Script Preparation Code** The script preparation code is empty, which means that no specific setup or initialization is required for the benchmark. **HTML Preparation Code** The HTML preparation code includes a simple `<div>` element with an ID of "foo", which will be used to test the `getComputedStyle` function. **Individual Test Cases** There are two individual test cases: 1. **"getComputedStyle"**: This test case uses the original `window.getComputedStyle` function directly. The script creates a `document.getElementById("foo")` element, sets up a loop that runs 3000 times, and inside the loop, calls the `chekele()` function, which checks if the `display` property of the element is not equal to "none" using `window.getComputedStyle`. 2. **"memoized getComputedStyle"**: This test case uses a memoized version of the `window.getComputedStyle` function. The script creates a `document.getElementById("foo")` element and sets up a similar loop as above, but this time it uses a cached version of `getComputedStyle` to avoid repeated calls to the original function. **Library Used** The `chekele()` function is assumed to be implemented separately, and its implementation is not provided in the benchmark definition. However, based on the test case code, it appears that `chekele()` is a custom function that checks if an element's `display` property is not equal to "none". **Special JS Features or Syntax** There are no special JavaScript features or syntax used in this benchmark. **Pros and Cons of Approaches** 1. **Original `window.getComputedStyle` approach**: * Pros: Simple and straightforward. * Cons: May result in repeated calls to `getComputedStyle`, which can be expensive due to the DOM manipulation involved. 2. **Memoized `window.getComputedStyle` approach**: * Pros: Avoids repeated calls to `getComputedStyle`, reducing the overhead of DOM manipulation. * Cons: Requires additional memory allocation for caching, and may have higher initialization overhead. **Other Considerations** 1. **Cache Hierarchy**: The memoized approach relies on a cache hierarchy to store the results of previous calls to `getComputedStyle`. This can lead to issues if multiple threads or processes access the same cached values. 2. **DOM Manipulation**: Both approaches involve DOM manipulation, which can be expensive and may affect performance. **Alternatives** If you need to benchmark similar scenarios, consider using a more robust testing framework that supports parallel execution, caching, and other optimization techniques. Some alternatives include: 1. **V8 Benchmarking**: Google's V8 JavaScript engine provides a built-in benchmarking suite for measuring the performance of JavaScript code. 2. **JSHint-Benchmark**: A tool that measures the performance of JavaScript code using JSHint's parser and execution model. 3. **Benchmark.js**: A lightweight benchmarking library for Node.js and browsers. Keep in mind that each alternative has its own strengths and weaknesses, and you should choose the one that best fits your specific use case.
Related benchmarks
jquery.css vs getComputedStyle
clientWidth vs offsetWidth vs window.getComputedStyle
clientWidth vs offsetWidth vs window.getComputedStyle v2
window.getComputedStyle vs. getBoundingClientRect width
Comments
Confirm delete:
Do you really want to delete benchmark?