Benchmark: intersect v2d - MeasureThat.net

Script Preparation code:

Array.prototype.shuffle = function() {
  let m = this.length, i;
  while (m) {
    i = (Math.random() * m--) >>> 0;
    [this[m], this[i]] = [this[i], this[m]]
  }
  return this;
};

var watched = [];
for(let i = 0; i < 100000; i++){watched.push({programId:Math.random()});}

var ignored = [...watched];
ignored.shuffle();
ignored = ignored.slice(50000, 59000);

Tests:

some
let i = 0; watched.filter(wObj => { return !ignored.some((iObj, ndx) => { i++; return iObj.programId === wObj.programId; }); }); console.log(i);
some; pop and swap
let i = 0; watched.filter(wObj => !ignored.some((iObj, ndx) => { if (iObj.programId === wObj.programId) { i++; ignored[ndx].programId = ignored.pop().programId; return true; } return false; }) ); console.log(i);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
some
some; pop and swap

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):

LLMs can make mistakes. Check important info.

I'll break down the provided JSON and explain what's being tested, compared, and their pros and cons.

**Benchmark Definition**

The benchmark definition is a JavaScript function that sets up a specific scenario for testing. It consists of three main parts:

1. **Script Preparation Code**: This code shuffles an array (`watched`) containing 100,000 objects with random `programId` values. The shuffled array is then sliced to exclude the first 50,000 elements and include only the last 45,000.
2. **Html Preparation Code**: There is no HTML preparation code provided, which means that this benchmark does not test anything related to rendering or DOM manipulation.

The purpose of these preparations is to create a scenario where a filter operation needs to be performed on the `watched` array. The filter operation will check if any element in the filtered array has a matching `programId` with an element in the ignored slice of the original array (`ignored`).

**Individual Test Cases**

There are two individual test cases:

1. **Test Case 1: "some"**
This test case simply applies a filter to the `watched` array, excluding any elements that have a matching `programId` with an element in the `ignored` slice.

Pros and Cons:

* Pros: This is a simple and straightforward filter operation.
* Cons: This test case may not accurately represent real-world scenarios where filtering operations are more complex.

2. **Test Case 2: "some; pop and swap"**
This test case applies a similar filter to the `watched` array, but with an additional step:

* It increments an index (`i`) while iterating over the filtered array.
* If a match is found, it swaps the corresponding elements in both the original and ignored slices.

Pros and Cons:

* Pros: This test case adds complexity to the filtering operation, making it more realistic for real-world scenarios.
* Cons: The additional step of swapping elements can introduce unnecessary overhead.

**Library and Special Features**

There are no libraries explicitly mentioned in the benchmark definition or test cases. However, the `filter()` method is used, which is a built-in JavaScript array method.

Special features:

* There are no special features like async/await, generators, or modern web APIs that would require specific support.
* The use of `>>> 0` for integer arithmetic and `Math.random()` is a basic feature of the JavaScript language.

**Other Alternatives**

If this benchmark were to be rewritten, alternative approaches could include:

* Using a different data structure, such as a Map or Set, instead of an array.
* Adding more complexity to the filtering operation, such as using regular expressions or advanced matching algorithms.
* Incorporating parallel processing or concurrency techniques to test performance in a multi-threaded environment.

Overall, this benchmark is designed to test the performance of JavaScript's built-in filtering operations on arrays. The comparison between the two test cases highlights the difference between simple and complex filter operations, which can help identify performance bottlenecks in real-world scenarios.

Latest run results:

Run details: (Test run date: 4 months ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0

Browser/OS: Chrome 125 on Windows

View result in a separate tab

Test name	Executions per second
some	0.4 Ops/sec
some; pop and swap	178.7 Ops/sec

Related benchmarks:

intersect v2d (version: 0)

Comparing performance of: some vs some; pop and swap

Created: 4 months ago by: Guest

Jump to the latest result

some

some; pop and swap

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one month ago):