Benchmark: test sort uniq2 - MeasureThat.net

HTML Preparation code:

<script src="https://cdnjs.cloudflare.com/ajax/libs/ramda/0.27.0/ramda.min.js"></script>

Script Preparation code:

var data = []

function getRandomDate() {
  const startMillis = new Date('2020-06-02T00:00:00.000Z').getTime();
  const endMillis = new Date().getTime();
  const randomMillis = startMillis + Math.random() * (endMillis - startMillis);
  const randomDate = new Date(randomMillis);

  return randomDate;
}

for (var i = 0; i < 14000; i++) {
     data.push({ customerId: `CTM-${i % 10}`, worklistId: `WL-${i % 100}`, createdDateTime: getRandomDate() });
}

Tests:

slow
var result = R.uniqBy( R.props(['worklistId', 'customerId']), [...data].sort( (a, b) => new Date(a.createdDateTime).getTime() - new Date(b.createdDateTime).getTime(), ), )
new
var result = R.uniqWith( (a, b) => a.customerId === b.customerId && a.worklistId === b.worklistId, [...data].sort( (a, b) => new Date(a.createdDateTime).getTime() - new Date(b.createdDateTime).getTime(), ), )
new2
var result = R.uniqWith( (a, b) => a.customerId === b.customerId && a.worklistId === b.worklistId, data.sort( (a, b) => a.createdDateTime - b.createdDateTime, ), )
nospread
var result = R.uniqWith( (a, b) => a.customerId === b.customerId && a.worklistId === b.worklistId, [...data].sort( (a, b) => a.createdDateTime - b.createdDateTime, ), )
nodate
var result = R.uniqWith( (a, b) => a.customerId === b.customerId && a.worklistId === b.worklistId, data.sort( (a, b) => new Date(a.createdDateTime).getTime() - new Date(b.createdDateTime).getTime(), ), )

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
slow
new
new2
nospread
nodate

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.

**Benchmark Overview**

The provided benchmark defines a set of test cases that compare different approaches to remove duplicates from an array of objects based on specific properties (worklistId and customerId). The tests are run using Ramda, a popular functional programming library for JavaScript.

**Test Case Breakdown**

Each test case has a unique name and a Benchmark Definition code, which specifies the approach used to remove duplicates. Let's break down each test case:

1. **"slow"**: This test uses the `R.uniq` function from Ramda, which removes duplicates based on the entire object being compared. The objects are first sorted by their createdDateTime property using a custom sorting function.
2. **"new"**: Similar to "slow", but it uses the `R.uniqWith` function with a callback that compares two objects based on their customerId and worklistId properties. This approach is more efficient than comparing entire objects, as it only checks for equality between specific fields.
3. **"new2"**: Another variant of "new", where the sorting function directly compares dates without using the `getTime()` method. This approach might be slower due to potential date parsing issues.
4. **"nospread"**: This test case removes the spread operator (`...`) from the `R.uniqWith` call, which means that Ramda will perform a deep comparison between objects instead of shallow equality checks. This can lead to more efficient performance but might also increase the chance of incorrect results due to object reference equality.
5. **"nodate"**: Similar to "nospread", this test case removes the date parsing from the sorting function, which means that the sorting will be done based on the natural ordering of dates.

**Pros and Cons**

Here's a brief summary of the pros and cons for each approach:

* **R.uniq** (Slow):
	+ Pros: Easy to use, no need to worry about specific property comparisons.
	+ Cons: Comparing entire objects can lead to slower performance and more memory usage.
* **R.uniqWith** (New, New2):
	+ Pros: More efficient than comparing entire objects, as it only checks for equality between specific fields.
	+ Cons: Requires more manual work to set up the callback function, which might be error-prone.
* **R.uniqWith** (Nospread, Nodate):
	+ Pros: Can lead to more efficient performance due to shallow comparison or direct date comparison.
	+ Cons: Might increase the chance of incorrect results due to object reference equality or date parsing issues.

**Library and Special JS Feature**

The `ramda` library is used extensively throughout these test cases. Ramda provides a set of functional programming utilities, including functions for array manipulation, data transformation, and more.

One special JavaScript feature used in this benchmark is the spread operator (`...`) which allows creating an array from an object by spreading its properties into individual elements. This feature was introduced in ECMAScript 2015 (ES6) as a part of the "Object rest/spread property" syntax.

**Other Alternatives**

If you're looking for alternative libraries or approaches, here are some options:

* **Lodash**: Another popular JavaScript library that provides an extensive set of utility functions, including array manipulation and data transformation.
* **Array.prototype.filter()**: A more straightforward approach to removing duplicates from an array by filtering out objects that have a duplicate key.
* **Set data structure**: Using a Set data structure can be an efficient way to remove duplicates from an array, as it automatically eliminates any duplicate values.

In conclusion, the choice of approach depends on your specific use case and performance requirements. If you need a simple solution with minimal code changes, `R.uniq` might be sufficient. However, if you require more control over the comparison process or better performance, using `R.uniqWith` with a custom callback function is likely a better option.

Latest run results:

Run details: (Test run date: one year ago)

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

Browser/OS: Chrome 119 on Windows

View result in a separate tab

Test name	Executions per second
slow	2.1 Ops/sec
new	14.0 Ops/sec
new2	85.1 Ops/sec
nospread	139.7 Ops/sec
nodate	70.8 Ops/sec

Related benchmarks:

test sort uniq2 (version: 0)

Comparing performance of: slow vs new vs new2 vs nospread vs nodate

Created: one year ago by: Guest

Jump to the latest result

slow

new

new2

nospread

nodate

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):