Benchmark: Intl.NumberFormat vs toLocalString vs string split vs toFixed vs bignumber

HTML Preparation code:

<script src="https://cdnjs.cloudflare.com/ajax/libs/bignumber.js/9.0.1/bignumber.min.js"></script>

Script Preparation code:

function pricize (num, decimal = 0) {
  const intPart = Math.floor(num)
  const intPieces = intPart.toString().split('')
  const len = intPieces.length
  const intStr = intPieces.reduce((result, chr, index, array) => {
    const pos = len - index
    result += (index !== 0 && pos % 3 === 0) ? ',' + chr : chr
    return result
  }, '')

  const decStr = decimal > 0
    ? num.toFixed(decimal + 1).toString().slice(-(decimal + 2), -1) // toFixed() は四捨五入してしまうので(decimal + 1)桁まで求めて切り取る
    : ''

  return intStr + decStr
}

var target = 123456789.123456789
var options = {minimumFractionDigits: 3, maximumFractionDigits: 3}

Tests:

toLocaleString
var a = target.toLocaleString('en-US', options);
Intl.NumberFormat
var a = new Intl.NumberFormat('en-US', options).format(target)
string split & reduce
var a = pricize(target, 3)
toFixed
var a = target.toFixed(3)
bignumber
var a = new BigNumber(target).toFixed(3)

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
toLocaleString
Intl.NumberFormat
string split & reduce
toFixed
bignumber

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 26 days ago):

LLMs can make mistakes. Check important info.

Let's dive into the benchmark and explore what's being tested.

**Benchmark Overview**

The benchmark compares four different approaches to format a number in JavaScript:

1. `toLocaleString` ( Intl.NumberFormat )
2. `string split & reduce`
3. `toFixed`
4. `bignumber`

Each approach has its pros and cons, which I'll outline below.

**1. `toLocaleString` ( Intl.NumberFormat )**

Pros:

* Most human-readable format
* Handles locale-specific formatting
* Typically faster than other methods

Cons:

* May not work correctly for all locales or edge cases
* Can be slower due to the overhead of creating an Intl.NumberFormat object
* Requires a compatible browser

In this benchmark, `toLocaleString` is being used with the `en-US` locale and a fixed options object. The test measures how quickly each approach can format the target number (`123456789.123456789`) as a string.

**2. `string split & reduce`**

Pros:

* Can produce a very human-readable format
* Flexible and customizable through the use of the `split()` method and a custom reduction function

Cons:

* May not be suitable for all types of numbers or formatting needs
* Can be slower due to the overhead of string manipulation
* Requires manual configuration and tweaking

In this benchmark, the `string split & reduce` approach uses a custom `pricize()` function to split the integer part of the number into individual characters, add commas as separators, and append the decimal part. The test measures how quickly each approach can produce this formatted string.

**3. `toFixed`**

Pros:

* Simple and straightforward
* Fast execution time

Cons:

* May not be suitable for all types of numbers or formatting needs (e.g., decimal places)
* Can result in truncated or rounded values
* Requires a compatible browser

In this benchmark, the `toFixed()` method is used to format the number with a fixed number of decimal places. The test measures how quickly each approach can produce this formatted string.

**4. `bignumber`**

Pros:

* Suitable for very large numbers
* Fast execution time
* Provides a clear and consistent formatting style

Cons:

* May not be suitable for all types of numbers or formatting needs (e.g., locale-specific formatting)
* Requires the bignumber library, which can add overhead to the benchmark
* Can result in a different formatting style than other approaches

In this benchmark, the `bignumber` library is used to format the number with fixed decimal places. The test measures how quickly each approach can produce this formatted string.

**Library and Special Features**

The benchmark uses the following libraries:

* bignumber.js (for the `bignumber` approach)
* Intl.NumberFormat API (for the `toLocaleString` approach)

No special JavaScript features or syntax are used in this benchmark, apart from some basic string manipulation in the `string split & reduce` approach.

**Alternatives**

If you're interested in exploring alternative approaches or optimization techniques, here are a few options:

* Use a more advanced formatting library, such as moment.js or date-fns.
* Implement custom formatting logic using only built-in JavaScript functions (e.g., string manipulation, template literals).
* Experiment with different browsers and device platforms to see how the performance differences vary.

Keep in mind that each approach has its pros and cons, and the best choice will depend on your specific use case and requirements.

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/126.0.0.0 YaBrowser/24.7.0.0 Safari/537.36

Browser/OS: Yandex Browser 24 on Windows

View result in a separate tab

Test name	Executions per second
toLocaleString	65443.8 Ops/sec
Intl.NumberFormat	42464.3 Ops/sec
string split & reduce	2898317.2 Ops/sec
toFixed	8469654.0 Ops/sec
bignumber	1415039.8 Ops/sec

Related benchmarks:

Intl.NumberFormat vs toLocalString vs string split vs toFixed vs bignumber (version: 0)

Comparing performance of: toLocaleString vs Intl.NumberFormat vs string split & reduce vs toFixed vs bignumber

Created: 2 years ago by: Guest

Jump to the latest result

toLocaleString

Intl.NumberFormat

string split & reduce

toFixed

bignumber

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 26 days ago):