Benchmark: big.js vs Fraction.js vs number-precision

HTML Preparation code:

<script src="https://cdn.jsdelivr.net/npm/big.js@6.2.2/big.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/fraction.js@5.2.1/dist/fraction.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/number-precision@1.6.0/build/index.iife.min.js"></script>

Script Preparation code:

/*your preparation JavaScript code goes here
To execute async code during the script preparation, wrap it as function globalMeasureThatScriptPrepareFunction, example:*/
async function globalMeasureThatScriptPrepareFunction() {
    // This function is optional, feel free to remove it.
    // await someThing();
}

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);
Big.js
var a = new Big("0.1"); var b = new Big("0.2"); a.plus(b).mul(b).toString();
Fraction.js
var a = new Fraction("0.1"); var b = new Fraction("0.2"); a.add(b).mul(b).toString();
number-precision
var a = 0.1; var b = 0.2; NP.times(NP.plus(a, b), b).toString()

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Native
Native + toFixed
Big.js
Fraction.js
number-precision

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 134 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Native	99127320.0 Ops/sec
Native + toFixed	16131546.0 Ops/sec
Big.js	3591213.8 Ops/sec
Fraction.js	1802781.9 Ops/sec
number-precision	749636.1 Ops/sec

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

LLMs can make mistakes. Check important info.

The benchmark you provided compares the performance of various approaches for performing arithmetic operations involving decimal numbers in JavaScript, specifically testing the addition and multiplication of decimal values 0.1 and 0.2. The different approaches include native JavaScript calculations along with the use of three external libraries: **Big.js**, **Fraction.js**, and **number-precision**.

### Approaches Compared:

1. **Native**
   ```javascript
   var a = 0.1;
   var b = 0.2;
   ((a + b) * b).toString();
   ```
   - **Description**: This approach uses standard JavaScript number types (which are IEEE 754 doubles). It performs the addition of `a` and `b`, multiplies the result by `b`, and converts the final result to a string.
   - **Pros**: Fastest execution as it utilizes the built-in number type without any overhead from libraries. 
   - **Cons**: Precision issues arise due to how floating-point arithmetic works in JavaScript, leading to results like `0.1 + 0.2 !== 0.3`.

2. **Native + toFixed**
   ```javascript
   var a = 0.1;
   var b = 0.2;
   ((a + b) * b).toFixed(9);
   ```
   - **Description**: Similar to the Native approach, but here the result is adjusted to 9 decimal places using `toFixed()`.
   - **Pros**: Can improve readability by providing a formatted string output without trailing decimal issues in some contexts.
   - **Cons**: While `toFixed()` can help with display issues, it does not fix the underlying floating-point precision problem in calculations. Performance is slower compared to the first approach.

3. **Big.js**
   ```javascript
   var a = new Big("0.1");
   var b = new Big("0.2");
   a.plus(b).mul(b).toString();
   ```
   - **Library**: **Big.js** is a library that can handle arbitrary-precision decimal arithmetic.
   - **Pros**: Avoids precision issues seen in native JavaScript by representing numbers in a way that doesn't suffer from floating-point representation inaccuracies.
   - **Cons**: Slower execution compared to native types due to the overhead of using an external library and creating Big.js objects.

4. **Fraction.js**
   ```javascript
   var a = new Fraction("0.1");
   var b = new Fraction("0.2");
   a.add(b).mul(b).toString();
   ```
   - **Library**: **Fraction.js** represents numbers as fractions. In this case, it converts the decimal strings into fractions (for example, `0.1` becomes `1/10`).
   - **Pros**: Avoids floating-point errors by working with rational numbers.
   - **Cons**: Similar to Big.js, there is a performance overhead due to the necessity of converting numbers to fractions, and it may be less intuitive to users comfortable with decimal arithmetic.

5. **number-precision**
   ```javascript
   var a = 0.1;
   var b = 0.2;
   NP.times(NP.plus(a, b), b).toString();
   ```
   - **Library**: **number-precision** is a library that adds methods for more precise number operations.
   - **Pros**: Aids in performing precise calculations, similarly avoiding the floating-point issues.
   - **Cons**: It has the performance costs associated with using any external library and may have slightly more complex syntax for developers familiar with basic arithmetic operations.

### Benchmark Results Overview:

The benchmark results indicate that the **Native** approach performed the best with approximately 99 million executions per second. The use of `toFixed()` reduced the performance substantially to about 16 million executions per second.

The libraries showed significantly lower performance. **Big.js** executed around 3.5 million times per second, **Fraction.js** around 1.8 million, and **number-precision** at approximately 749,000. This highlights the trade-off between performance and precision when using external libraries.

### Other Considerations:

- **Precision vs Performance**: There's a clear trade-off with libraries like Big.js and Fraction.js, which prioritize precision over performance. While using native types is faster, it introduces potential inaccuracies in calculations that can lead to subtle bugs, especially evident in financial applications.

- **Alternatives**: Besides these libraries, there are other libraries and strategies in JavaScript for dealing with decimal precision. For example, libraries like **decimal.js** and **bignumber.js** provide similar functionality with different implementations and performance characteristics.

In conclusion, the choice between native operations and libraries depends heavily on the specific application needs regarding performance requirements and precision handling. For applications requiring high precision and correctness in decimal arithmetic, using libraries is advisable despite the performance hit, while for less critical applications, native operations may suffice.

Related benchmarks:

big.js vs Fraction.js vs number-precision (version: 1)

Comparing performance of: Native vs Native + toFixed vs Big.js vs Fraction.js vs number-precision

Created: one month ago by: Guest

Jump to the latest result

Native

Native + toFixed

Big.js

Fraction.js

number-precision

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