Toggle navigation
MeasureThat.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
immutable-js Set some vs intersect
(version: 0)
Comparing performance of:
some large to small vs some small to large vs intersect large to small vs intersect small to large
Created:
7 years ago
by:
Guest
Jump to the latest result
HTML Preparation code:
<script src="https://cdnjs.cloudflare.com/ajax/libs/immutable/3.8.1/immutable.min.js"></script>
Script Preparation code:
var source = []; for (let ii = 0, len = 26, iChar = 65; ii < len; ii++) { for (let jj = 0, jlen = 100; jj < jlen; jj++) { source.push(`${String.fromCharCode(iChar + ii)}${`${jj}`.padStart(3, '0')}`); } } var CONTROLLER_FILTERS = Immutable.Set(['B007', 'R035', 'Z094']); var filters = Immutable.Set(source);
Tests:
some large to small
const isTrue = filters.some( filter => CONTROLLER_FILTERS.includes(filter), ); result = false; if (isTrue) { result = true; }
some small to large
const isTrue = CONTROLLER_FILTERS.some( filter => filters.includes(filter), ); result = false; if (isTrue) { result = true; }
intersect large to small
const active = filters.intersect(CONTROLLER_FILTERS); result = false; if (active.size > 0) { result = true; }
intersect small to large
const active = CONTROLLER_FILTERS.intersect(filters); result = false; if (active.size > 0) { result = true; }
Rendered benchmark preparation results:
Suite status:
<idle, ready to run>
Run tests (4)
Previous results
Fork
Test case name
Result
some large to small
some small to large
intersect large to small
intersect small to large
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):
Let's dive into the world of JavaScript microbenchmarks on MeasureThat.net. The benchmark you provided measures the performance of various approaches when testing whether an element is present in a set using the `some()` method or intersection operation with `intersect()`. We'll break down each test case and explore the options being compared, their pros and cons, and other considerations. **Test Case 1: "some large to small"** This test case compares the performance of using `filters.some(filter => CONTROLLER_FILTERS.includes(filter))` versus a direct comparison with `CONTROLLER_FILTERS.includes(filter)`. The idea is to start with a larger set (100 elements) and gradually decrease its size while maintaining the same filtering logic. Pros: * This approach allows for a controlled increase in element count, making it easier to isolate performance differences. * It's a more realistic scenario, as developers often work with large datasets. Cons: * The direct comparison might be faster due to less overhead from method calls and potential caching. **Test Case 2: "some small to large"** This test case is similar to the first one but starts with a smaller set (3 elements) and gradually increases its size. This approach allows for a more controlled exploration of performance differences when using `includes()` method versus `some()`. Pros: * Similar to Test Case 1, this approach helps isolate performance differences between methods. * It's useful for identifying how the performance changes as the dataset grows. Cons: * The smaller starting set might not accurately represent real-world scenarios where datasets can be massive. **Test Case 3: "intersect large to small"** This test case compares the performance of using `filters.intersect(CONTROLLER_FILTERS)` versus a direct comparison with `CONTROLLER_FILTERS.includes(filter)`. Similar to Test Case 1, it starts with a larger set and decreases its size while maintaining the same intersection logic. Pros: * Allows for controlled exploration of performance differences between methods. * Helps identify how performance changes as the dataset grows. Cons: * The direct comparison might be faster due to less overhead from method calls and potential caching. **Test Case 4: "intersect small to large"** This test case is similar to Test Case 3 but starts with a smaller set. It helps identify performance differences when using `includes()` versus `intersect()` for intersection operations. Pros: * Helps isolate performance differences between methods. * Useful for understanding how performance changes as the dataset grows. **Libraries and Features Used** The benchmark uses the Immutable.js library, which is a popular JavaScript library for functional programming. Specifically, it utilizes the `Immutable.Set` data structure to represent sets. No special JavaScript features or syntax are mentioned in this benchmark. **Other Alternatives** For comparison purposes, other methods could be used, such as: * Using `Array.prototype.includes()` directly on the set elements instead of `CONTROLLER_FILTERS.includes(filter)` * Implementing a custom `includes()` method for the set data structure * Comparing performance with different caching strategies or optimization techniques Keep in mind that these alternatives might not provide meaningful results without significant modifications to the benchmark. I hope this explanation helps you understand the test cases and options being compared in the MeasureThat.net benchmark!
Related benchmarks:
object spread vs immutable-js set2
array slice vs immutable-js takeLast
Immutable.Set Union vs Constructing a new plain JS Set
Immutable.Set Union vs Constructing a new plain JS Set - small
immutable vs Native Javascript Map With Read Complex
Comments
Confirm delete:
Do you really want to delete benchmark?