Benchmark: FP-ts vs native - MeasureThat.net

Script Preparation code:

some = (set, predicate) => {
    const values = set.values()
    let e
    let found = false
    while (!found && !(e = values.next()).done) {
      found = predicate(e.value)
    }
    return found
  }
a = Array.from({length: 800}, i => i)
s = new Set(a)

Tests:

fp-ts set
const r = some(s,(v) => v == 301 )
native set
const r = s.has(301)
native array
const r = a.some(v => v == 301)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
fp-ts set
native set
native array

Fastest: N/A

Slowest: N/A

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

LLMs can make mistakes. Check important info.

Let's break down the provided JSON data and explain what's being tested.

**Benchmark Definition**

The benchmark is testing three different approaches to check if an element (in this case, 301) exists in a set or array:

1. **FP-ts set**: This approach uses the `some` function from the FP-ts library, which is a functional programming library for TypeScript and JavaScript. The `some` function returns `true` as soon as it finds an element that satisfies the provided predicate (in this case, `v => v == 301`). If no such element is found after iterating over all elements in the set, it returns `false`.
2. **Native set**: This approach uses a simple `has` method on the native JavaScript Set object to check if the element exists.
3. **Native array**: This approach uses the `some` function from the native JavaScript Array prototype to check if an element satisfies the provided predicate.

**Options Compared**

The benchmark is comparing the performance of these three approaches:

* FP-ts set: This approach has access to additional functional programming features and data structures, which may lead to more efficient or idiomatic implementations.
* Native set: This approach uses native JavaScript built-in methods, which are typically optimized for performance and should be fast.
* Native array: Similar to the native set, this approach uses native JavaScript built-in methods, but on an array.

**Pros and Cons**

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

* **FP-ts set**: Pros:
	+ Access to functional programming features and data structures, which can lead to more efficient or idiomatic implementations.
	+ May be more concise and expressive code.
Cons:
	+ Requires importing the FP-ts library, which may add overhead.
	+ May not be as widely supported or optimized for performance.
* **Native set**: Pros:
	+ Optimized for performance by native JavaScript built-in methods.
	+ Widely supported across browsers and platforms.
Cons:
	+ May require more boilerplate code to achieve the same result as FP-ts set.
* **Native array**: Similar pros and cons as native set, but with the added benefit of using a more concise `some` function.

**Library**

The `FP-ts` library is a functional programming library for TypeScript and JavaScript that provides a range of data structures and functions for building composable, predictable code. In this benchmark, the `some` function from FP-ts is used to check if an element exists in a set.

**Special JS Feature or Syntax**

There are no special JavaScript features or syntaxes being used in this benchmark, aside from the use of ES6-style arrow functions and template literals (e.g., `"const r = some(s,(v) => v == 301 )"`).

**Alternatives**

Other alternatives for checking if an element exists in a set or array include:

* Using `includes` method on native JavaScript Sets or Arrays, which is a more concise and expressive way to check for membership.
* Implementing a custom loop or recursive function to iterate over the elements and check for existence.
* Using third-party libraries like Lodash or Ramda, which provide additional functional programming utilities and data structures.

It's worth noting that the choice of approach ultimately depends on the specific requirements of the project and the trade-offs between performance, readability, and maintainability.

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36

Browser/OS: Chrome 124 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
fp-ts set	8006396.0 Ops/sec
native set	16248855.0 Ops/sec
native array	367519.4 Ops/sec

Related benchmarks:

FP-ts vs native (version: 0)

Comparing performance of: fp-ts set vs native set vs native array

Created: 10 months ago by: Guest

Jump to the latest result

fp-ts set

native set

native array

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