Benchmark: JS BigInt big number performance v5

Script Preparation code:

var bigInt1 = 1000000n
var bigInt2 = 50n
var number1 = 1000000
var number2 = 50

Tests:

Number
a = number1 b = number2 c = a - b c = a * b c = a + b c = a / b
BigInt
a = bigInt1 b = bigInt2 c = a - b c = a * b c = a + b c = a / b

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Number
BigInt

Fastest: N/A

Slowest: N/A

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/134.0.0.0 Safari/537.36

Browser/OS: Chrome 134 on Windows

View result in a separate tab

Test name	Executions per second
Number	2362807.5 Ops/sec
BigInt	2244147.0 Ops/sec

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

LLMs can make mistakes. Check important info.

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

**What is being tested?**

MeasureThat.net is testing the performance of two types of numbers in JavaScript: `Number` and `BigInt`. Specifically, it's comparing the performance of arithmetic operations (addition, subtraction, multiplication, and division) on both types of numbers.

**Options compared**

The benchmark compares the performance of `Number` and `BigInt` for the following arithmetic operations:

1. Addition (`a + b`)
2. Subtraction (`a - b`)
3. Multiplication (`a * b`)
4. Division (`a / b`)

**Pros and cons of each approach**

**Number**

Pros:

* Wide support across most browsers and JavaScript engines
* Fast execution speed due to the use of optimized integer arithmetic

Cons:

* Can lead to precision issues for large numbers, as the number is represented in binary format (32 bits on most systems)
* May not be suitable for cryptographic applications or scenarios where precise control over decimal representation is required

**BigInt**

Pros:

* Provides arbitrary-precision arithmetic, allowing for very large numbers without loss of precision
* Suitable for cryptographic applications and other use cases requiring precise decimal representation

Cons:

* Limited support across older browsers and JavaScript engines (although this is improving with newer versions)
* May have performance implications due to the use of larger data structures and potentially slower execution speeds compared to `Number`

**Library usage**

In the benchmark, the `BigInt` library is used for its implementation. Specifically, it's using the `n` syntax introduced in ECMAScript 2020 to represent large integers.

For those unfamiliar with `n`, it represents a BigInt literal, allowing for arbitrary-precision arithmetic. This syntax was added to provide support for cryptographic primitives and other use cases requiring precise decimal representation.

**Special JS feature or syntax**

The benchmark uses the `n` syntax to represent large integers using `BigInt`. This is a relatively recent addition to JavaScript (introduced in ECMAScript 2020) and provides a convenient way to work with arbitrary-precision numbers.

**Other alternatives**

If you're working with very large numbers or require precise control over decimal representation, other alternatives might include:

1. libraries like `jsbn` or `decimal.js`, which provide support for arbitrary-precision arithmetic in JavaScript.
2. specialized libraries like `crypto-js` or `big-integer`, which offer a range of cryptographic primitives and functions.

However, keep in mind that these alternatives may have different performance characteristics, compatibility issues, or additional complexity compared to the built-in `BigInt` implementation in modern browsers and JavaScript engines.

Related benchmarks:

JS BigInt big number performance v5 (version: 0)

Compare Number vs BigInt for big numbers

Comparing performance of: Number vs BigInt

Created: 2 years ago by: Guest

Jump to the latest result

Number

BigInt

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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