Benchmark: bignumber.js vs. big.js vs. decimal.js only calculation without toString()

bignumber.js vs. big.js vs. decimal.js only calculation without toString() (version: 0)

- https://github.com/MikeMcl/bignumber.js/tree/v9.0.0 - https://github.com/MikeMcl/big.js/tree/v5.2.2 - https://github.com/MikeMcl/decimal.js/tree/v10.2.0

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

Created: one year ago by: Guest

Jump to the latest result

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://cdnjs.cloudflare.com/ajax/libs/decimal.js/10.2.1/decimal.min.js"></script>
<!--script src="https://raw.githubusercontent.com/infusion/Fraction.js/v4.0.12/fraction.min.js"></script-->

Tests:

Native
var a = 0.1; var b = 0.2; ((a + b) * b);
Native + toFixed
var a = 0.1; var b = 0.2; ((a + b) * b);
decimal.js
var a = new Decimal("0.1"); var b = new Decimal("0.2"); a.plus(b).times(b);
big.js
var a = new Big("0.1"); var b = new Big("0.2"); a.plus(b).mul(b);
bignumber.js
var a = new BigNumber("0.1"); var b = new BigNumber("0.2"); a.plus(b).multipliedBy(b);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Native
Native + toFixed
decimal.js
big.js
bignumber.js

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; rv:109.0) Gecko/20100101 Firefox/119.0

Browser/OS: Firefox 119 on Windows

View result in a separate tab

Test name	Executions per second
Native	946886400.0 Ops/sec
Native + toFixed	940900992.0 Ops/sec
decimal.js	678699.4 Ops/sec
big.js	1002983.4 Ops/sec
bignumber.js	563807.6 Ops/sec

Autogenerated LLM Summary (model gemma2:9b, generated 2 months ago):

LLMs can make mistakes. Check important info.

This benchmark compares the performance of different JavaScript libraries and plain JavaScript for performing a simple calculation involving floating-point numbers:

`(a + b) * b`

where `a` is 0.1 and `b` is 0.2.

Let's break down the options being compared:

* **Native:** This test uses standard JavaScript's built-in operators for arithmetic calculations.
* **Native + toFixed:** This test is similar to "Native" but applies `toFixed()` after the calculation to ensure a consistent string representation of the result.

* **decimal.js:** This library is designed for precise decimal arithmetic, avoiding common floating-point inaccuracies that can occur in JavaScript's native implementation.

* **big.js:**  Another library focused on arbitrary precision arithmetic. It handles numbers with large magnitudes or high degrees of accuracy.
* **bignumber.js:** Similar to `big.js`, this library provides support for arbitrarily large numbers, aiming to minimize rounding errors common in standard JavaScript.

**Pros and Cons:**

| Library/Approach | Pros                                     | Cons                                   |
|------------------|------------------------------------------|---------------------------------------|
| **Native**         | Simple, widely supported                 | Prone to floating-point inaccuracies |
| **Native + toFixed** | Attempts to mitigate floating-point issues|  Can introduce rounding errors itself   |
| **decimal.js**     | Precise decimal arithmetic              | Can be slower than native approaches    |
| **big.js**         | Arbitrary precision                     | Potentially less performant for small calculations |
| **bignumber.js** | Similar to `big.js`                       |  Can be resource-intensive            |

**Other Considerations:**

* **Use Case:** Choose the library that best suits your application's needs. If you require extreme precision or handle very large numbers, libraries like `big.js` and `bignumber.js` are essential. For everyday calculations where accuracy is not critical, native JavaScript might be sufficient.
* **Performance Impact:**  Libraries often introduce overhead compared to plain JavaScript. Carefully evaluate the performance trade-offs.

**Alternatives:**

While this benchmark focuses on specific libraries, other approaches exist for managing floating-point precision in JavaScript:

* Custom Rounding Functions: Implement your own rounding algorithms to control how numbers are represented.
* Libraries like `Fraction.js`: This library works with rational numbers (fractions), providing precise representation and arithmetic operations.

Remember that the best approach depends on your specific requirements and project context.

Related benchmarks:

bignumber.js vs. big.js vs. decimal.js only calculation without toString() (version: 0)

- https://github.com/MikeMcl/bignumber.js/tree/v9.0.0 - https://github.com/MikeMcl/big.js/tree/v5.2.2 - https://github.com/MikeMcl/decimal.js/tree/v10.2.0

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

Created: one year ago by: Guest

Jump to the latest result

Native

Native + toFixed

decimal.js

big.js

bignumber.js

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gemma2:9b, generated 2 months ago):