Benchmark: native vs native big vs bignumber.js vs. big.js vs break_infinity.js

HTML Preparation code:

<!--script src="https://raw.githubusercontent.com/iriscouch/bigdecimal.js/v0.6.1/lib/bigdecimal.js"></script-->
<script src="https://cdnjs.cloudflare.com/ajax/libs/bignumber.js/9.0.1/bignumber.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/big.js/6.0.3/big.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/break_infinity.js@2"></script>
<!--script src="https://raw.githubusercontent.com/infusion/Fraction.js/v4.0.12/fraction.min.js"></script-->

Tests:

Native
var a = 1; var b = 2; ((a + b) * b).toString();
Native + toFixed
var a = 1; var b = 2; ((a + b) * b).toFixed(9);
break_infinity.js
var a = new Decimal("1"); var b = new Decimal("2"); a.plus(b).times(b).toString();
big.js
var a = new Big("1"); var b = new Big("2"); a.plus(b).mul(b).toString();
bignumber.js
var a = new BigNumber("1"); var b = new BigNumber("2"); a.plus(b).multipliedBy(b).toString();
native big
var a = 1n; var b = 2n; ((a + b) * b).toString();

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Native
Native + toFixed
break_infinity.js
big.js
bignumber.js
native big

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 28 days 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
Native	157529200.0 Ops/sec
Native + toFixed	23329950.0 Ops/sec
break_infinity.js	12006275.0 Ops/sec
big.js	5921856.0 Ops/sec
bignumber.js	3651282.5 Ops/sec
native big	59505612.0 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated 5 months ago):

LLMs can make mistakes. Check important info.

The benchmark defined in the provided JSON compares the performance of various approaches to performing arithmetic operations in JavaScript, specifically focusing on native number handling versus several libraries designed for handling large or precise numbers. The test cases examine different methods for adding two numbers and multiplying the result by one of the original numbers. Below, we break down each option, its pros and cons, and provide insights into the libraries involved.

### Test Cases Overview:

1. **Native**:
   - Code: `var a = 1; var b = 2; ((a + b) * b).toString();`
   - This test uses JavaScript’s native number type (which is a double-precision 64-bit binary format).
   - **Pros**: Faster execution speed; minimal overhead.
   - **Cons**: Limited precision for very large numbers (greater than 2^53), can lead to rounding errors.

2. **Native + toFixed**:
   - Code: `var a = 1; var b = 2; ((a + b) * b).toFixed(9);`
   - This variation adds a formatting function (`toFixed`) to limit the decimal places to 9.
   - **Pros**: Provides control over the number's decimal precision.
   - **Cons**: Slower execution than pure native operations due to additional processing; could still face precision issues with very large numbers.

3. **break_infinity.js**:
   - Code: `var a = new Decimal("1"); var b = new Decimal("2"); a.plus(b).times(b).toString();`
   - This test uses the `break_infinity.js` library, which is designed for arbitrary-precision arithmetic.
   - **Pros**: Allows calculations with very large and very small numbers without precision loss.
   - **Cons**: More overhead due to the creation of objects and additional method calls, resulting in slower execution compared to native options.

4. **big.js**:
   - Code: `var a = new Big("1"); var b = new Big("2"); a.plus(b).mul(b).toString();`
   - This utilizes the `big.js` library, which offers arbitrary precision decimal arithmetic.
   - **Pros**: Avoids precision issues associated with JavaScript's native number type; ideal for financial and scientific calculations.
   - **Cons**: Significant overhead due to object instantiation and method chaining, leading to reduced performance.

5. **bignumber.js**:
   - Code: `var a = new BigNumber("1"); var b = new BigNumber("2"); a.plus(b).multipliedBy(b).toString();`
   - Here, the `bignumber.js` library is employed, which is also focused on high-precision arithmetic.
   - **Pros**: Similar advantages as `big.js` in terms of avoiding precision loss.
   - **Cons**: Performance costs associated with using library functions, which are typically slower than native operations.

6. **Native Big**:
   - Code: `var a = 1n; var b = 2n; ((a + b) * b).toString();`
   - This case uses BigInt (`n` suffix) for large integers.
   - **Pros**: Provides a way to handle integers larger than `2^53` with full precision.
   - **Cons**: BigInt doesn’t support fractions (no decimal numbers); using it with regular numbers may require conversions.

### Performance Results:

Reviewing the performance metrics indicates that the native operations (both plain and with `toFixed`) perform significantly faster than any library-based solution. In contrast, `big.js`, `bignumber.js`, and `break_infinity.js` demonstrate much lower execution speeds due to the overhead from object creation and method calls. The `big.js` and `bignumber.js` libraries are also significantly slower than `decimal`.

### Other Considerations and Alternatives:

- **Precision vs. Performance**: This benchmark starkly illustrates the trade-off between precision and speed. While native operations are faster, they can lead to significant issues with precision in calculations involving very large or very small numbers.
- **Alternatives**: Other libraries, such as `decimal.js`, are also popular for similar requirements. Different libraries might offer varying performance and features, so the choice of library may depend on specific use cases, such as financial calculations or scientific computing.
- Users may also consider other techniques, such as implementing a caching mechanism or utilizing WebAssembly for performance-critical applications involving complex numerical computation.

### Summary

The benchmark assesses various approaches to managing numerical computation in JavaScript, emphasizing the performance impacts of using native types versus specialized libraries. Understanding these distinctions enables developers to select the appropriate method based on the specific use case, emphasizing the importance of balancing precision and performance in JavaScript arithmetic operations.

Related benchmarks:

native vs native big vs bignumber.js vs. big.js vs break_infinity.js (version: 1)

Comparing performance of: Native vs Native + toFixed vs big.js vs bignumber.js vs break_infinity.js

Comparing performance of: Native vs Native + toFixed vs break_infinity.js vs big.js vs bignumber.js vs native big

Created: 5 months ago by: Guest

Jump to the latest result

Native

Native + toFixed

break_infinity.js

big.js

bignumber.js

native big

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 5 months ago):