Benchmark: Number#toLocaleString () vs Intl.NumberFormat#format()

Script Preparation code:

globalThis.value = 1234.56789;
globalThis.options = {
    signDisplay: 'negative',
    maximumFractionDigits: 16,
};
globalThis.numberFormat = Intl.NumberFormat(undefined, options);

Tests:

Intl.NumberFormat#format()
numberFormat.format(value);
Number#toLocaleString()
value.toLocaleString(undefined, options);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Intl.NumberFormat#format()
Number#toLocaleString()

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 11 months ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0

Browser/OS: Firefox 140 on Windows

View result in a separate tab

Test name	Executions per second
Intl.NumberFormat#format()	3764285.8 Ops/sec
Number#toLocaleString()	89386.9 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down the provided benchmark and its test cases.

**Benchmark Definition JSON**

The benchmark is comparing two approaches for formatting numbers:

1. `Intl.NumberFormat#format()`: This method uses the Internationalization API to format numbers according to the locale and options specified. In this case, the locale is set to "undefined" (which means the system's default locale will be used), and the options include:
	* `signDisplay: 'negative'`: Display negative signs.
	* `maximumFractionDigits: 16`: Maximum number of decimal places to display.
2. `Number#toLocaleString()`: This method formats numbers using the system's default localization settings.

**Pros and Cons**

Both approaches have their strengths:

* `Intl.NumberFormat#format()`:
	+ Pros:
		- More control over formatting options (e.g., locale, decimal separator, thousands separator).
		- Can handle complex number formatting scenarios.
	+ Cons:
		- May be slower due to the overhead of internationalization and locale switching.
		- Requires more memory usage for storing the locale and options.
* `Number#toLocaleString()`:
	+ Pros:
		- Faster execution, as it leverages the system's default localization settings.
		- Less memory usage compared to `Intl.NumberFormat#format()`.

**Library: Intl.NumberFormat**

The `Intl.NumberFormat` library is part of the Internationalization API in JavaScript. It provides a way to format numbers according to the specified locale and options. The library is used to create an instance that can be used to format numbers, as shown in the benchmark definition:

```javascript
globalThis.numberFormat = Intl.NumberFormat(undefined, options);
```

**Special JS Feature: Template Literals**

The test cases use template literals (`"numberFormat.format(value);"` and `"value.toLocaleString(undefined, options);"`). Template literals are a feature introduced in ECMAScript 2015 (ES6) that allow you to embed expressions inside string literals. In this case, the `format()` method is called on the formatted number value.

**Other Alternatives**

If you want to compare formatting numbers without using internationalization or template literals, you could use other approaches:

1. Use a library like [Mathjs](https://mathjs.org/), which provides a way to format numbers according to specific rules (e.g., decimal places, thousands separators).
2. Implement custom number formatting logic in your JavaScript code.
3. Compare the execution times of different formatting libraries or frameworks.

Keep in mind that each alternative will have its pros and cons, and may not provide the same level of control or flexibility as the `Intl.NumberFormat` library.

Related benchmarks:

Number#toLocaleString () vs Intl.NumberFormat#format() (version: 0)

Comparing performance of: Intl.NumberFormat#format() vs Number#toLocaleString()

Created: 2 years ago by: Guest

Jump to the latest result

Intl.NumberFormat#format()

Number#toLocaleString()

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):