Toggle navigation
MeasureThat.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
cached matchMedia
(version: 0)
Comparing performance of:
cached MediaQueryList vs non-cached MediaQueryList
Created:
7 years ago
by:
Guest
Jump to the latest result
Script Preparation code:
window.mql = window.matchMedia('(min-width: 400px)');
Tests:
cached MediaQueryList
window.mql.matches;
non-cached MediaQueryList
window.matchMedia('(min-width: 400px)');
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (2)
Previous results
Fork
Test case name
Result
cached MediaQueryList
non-cached MediaQueryList
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/136.0.0.0 Safari/537.36
Browser/OS:
Chrome 136 on Mac OS X 10.15.7
View result in a separate tab
Embed
Embed Benchmark Result
Test name
Executions per second
cached MediaQueryList
4048111.8 Ops/sec
non-cached MediaQueryList
1574030.2 Ops/sec
Autogenerated LLM Summary
(model
llama3.2:3b
, generated one year ago):
**What is tested on the provided JSON?** The provided JSON represents two test cases for measuring the performance of JavaScript microbenchmarks related to the `matchMedia` API. 1. **Cached MediaQueryList**: This test case measures the performance of accessing the `matches` property of a cached ` MediaQueryList` object. The caching mechanism is used when the same media query is used multiple times in quick succession. 2. **Non-cached MurdochMediaList**: This test case measures the performance of creating and accessing a new `MediaQueryList` object without using any caching mechanisms. **Options compared** Two options are being compared: 1. **Cached MediaQueryList**: Using caching to improve performance when the same media query is used multiple times. 2. **Non-cached MurdochMediaList**: Not using caching, which may lead to slower performance due to the overhead of creating a new `MediaQueryList` object each time. **Pros and Cons** **Cached MediaQueryList:** Pros: * Improves performance by reducing the number of DOM mutations required for subsequent requests * Reduces CPU overhead by reusing cached results Cons: * May lead to slower initial performance due to the need to cache the media query result * May not be suitable for all use cases where caching is not feasible or desirable **Non-cached MurdochMediaList:** Pros: * Can provide accurate measurements of non-cached performance * Does not rely on caching, which can be beneficial in certain scenarios Cons: * Slower performance due to the overhead of creating a new `MediaQueryList` object each time * May lead to inaccurate results if caching is enabled elsewhere in the application **Other considerations** The choice between these two approaches depends on the specific use case and requirements. If the same media query is used multiple times in quick succession, using caching can improve performance. However, if accuracy and non-cached performance are more important, not using caching may be a better option. **Library and purpose** In the provided benchmark code, ` MurdochMediaList` is mentioned, but it seems to be an error or a placeholder. In reality, there is no such library as MurdochMediaList in JavaScript. It's likely that the author meant to use ` MediaQueryList`, which is part of the `matchMedia` API. **Special JS feature or syntax** There are no special features or syntax used in this benchmark code that require specific knowledge beyond what is provided by the standard JavaScript language. I hope this explanation helps!
Related benchmarks:
client width vs matchmedia
matchMedia vs clientWidth vs innerWidth
matchMedia (multiple queries) vs clientWidth vs innerWidth
matchMedia vs cached matchMedia
Comments
Confirm delete:
Do you really want to delete benchmark?