Benchmark: bignumber.js vs. big.js vs. decimal.js vs currency.js

bignumber.js vs. big.js vs. decimal.js vs currency.js (version: 1)

- 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 - https://github.com/scurker/currency.js/tree/v2.0.4

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

Created: one month 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://unpkg.com/currency.js@2.0.4/dist/currency.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).toString();
Native + toFixed
var a = 0.1; var b = 0.2; ((a + b) * b).toFixed(9);
decimal.js
var a = new Decimal("0.1"); var b = new Decimal("0.2"); a.plus(b).times(b).toString();
big.js
var a = new Big("0.1"); var b = new Big("0.2"); a.plus(b).mul(b).toString();
bignumber.js
var a = new BigNumber("0.1"); var b = new BigNumber("0.2"); a.plus(b).multipliedBy(b).toString();
currency.js
var a = 0.1; var b = 0.2; currency(a).add(b).multiply(b).toString()

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
currency.js

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 131 on Windows

View result in a separate tab

Test name	Executions per second
Native	73116304.0 Ops/sec
Native + toFixed	6195317.0 Ops/sec
decimal.js	697352.7 Ops/sec
big.js	1178687.8 Ops/sec
bignumber.js	723895.8 Ops/sec
currency.js	438439.8 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated one month ago):

LLMs can make mistakes. Check important info.

The benchmark you provided tests the performance of various libraries for handling numerical calculations in JavaScript. Specifically, it compares the following libraries: **bignumber.js**, **big.js**, **decimal.js**, and **currency.js** against native JavaScript number operations.

### Benchmark Overview

1. **Native JavaScript Operations**:
   - **Test Cases**:
     - **Native**: Direct addition and multiplication of numbers (0.1 + 0.2) * 0.2.
     - **Native + toFixed**: Similar calculation but applies the `toFixed` method for formatting the result to a string with a specific number of decimal places.
   - **Pros**: Fastest execution and simple to implement.
   - **Cons**: Precision issues with floating point arithmetic. For example, 0.1 + 0.2 does not equal 0.3 in JavaScript due to binary floating point representation limitations.

2. **bignumber.js**:
   - **Test Case**: Uses `BigNumber` to handle precision for the same operation.
   - **Pros**: Handles arbitrary precision arithmetic; reduces error in floating point calculations.
   - **Cons**: Slower than native operations due to overhead of the library's handling.

3. **big.js**:
   - **Test Case**: Utilizes the `Big` constructor for precise calculations.
   - **Pros**: Similar to bignumber.js, it provides a simple API for arbitrary precision arithmetic.
   - **Cons**: Performance is significantly lower than native operations and can be slower than bignumber.js.

4. **decimal.js**:
   - **Test Case**: Uses the `Decimal` type to perform calculations.
   - **Pros**: Offers a wide range of mathematical functions with high precision.
   - **Cons**: Performance is lower compared to native methods and the other libraries listed.

5. **currency.js**:
   - **Test Case**: Designed specifically for currency operations. The example involves adding two numbers and then multiplying.
   - **Pros**: Provides support for common currency operations and prevents floating-point inaccuracies.
   - **Cons**: The execution speed is the slowest among the tested cases, as it adds additional overhead for currency-specific features.

### Summary of Performance Results
According to the benchmark results:
- Native operations performed at **73,116,304 executions per second**, clearly outperforming other methods.
- The addition of `toFixed` dropped performance to **6,195,317** executions per second due to formatting overhead but still provided the benefit of output precision.
- After that, **big.js** achieved around **1,178,688** executions per second, while **bignumber.js**, **decimal.js**, and **currency.js** had progressively lower execution speeds, with **currency.js** at **438,440** executions per second.

### Other Considerations
- **Precision vs Performance**: Choosing the right library often involves a trade-off between performance and precision. If performance is critical and acceptable channels of error can be tolerated, JavaScript's native operations might be preferable. For applications requiring high precision, such as financial calculations, a dedicated library should be considered despite reduced performance.
- **Use Cases**: The selection of a numerical library should depend on the specific needs of the project. If calculations need to be precise and error-free, especially in financial or scientific applications, libraries like `big.js` or `bignumber.js` are suitable. For currency-related tasks, `currency.js` offers features tailored to that domain.
- **Future Alternatives**: Other alternatives may include libraries such as `math.js` which provides both numeric computing capabilities as well as symbolic computations but might not specialize as effectively in precision management as the dedicated libraries mentioned.

In conclusion, the choice of numerical handling in JavaScript involves carefully weighing precision, performance, and the specific requirements of the application at hand. Understanding both the capabilities and limitations of these libraries is essential for software engineers when architecting a solution.

Related benchmarks:

bignumber.js vs. big.js vs. decimal.js vs currency.js (version: 1)

- 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 - https://github.com/scurker/currency.js/tree/v2.0.4

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

Created: one month ago by: Guest

Jump to the latest result

Native

Native + toFixed

decimal.js

big.js

bignumber.js

currency.js

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated one month ago):