Benchmark: immutable-js Set some vs intersect

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>

Previous results

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

Autogenerated LLM Summary (model llama3.2:3b, generated 29 days ago):

LLMs can make mistakes. Check important info.

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!

Latest run results:

Run details: (Test run date: 5 years ago)

User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36

Browser/OS: Chrome 74 on Linux

View result in a separate tab

Test name	Executions per second
some large to small	70077.3 Ops/sec
some small to large	743535.5 Ops/sec
intersect large to small	606.8 Ops/sec
intersect small to large	488175.9 Ops/sec

Related benchmarks:

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: 5 years ago by: Guest

Jump to the latest result

some large to small

some small to large

intersect large to small

intersect small to large

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 29 days ago):