Benchmark: Intl.NumberFormat vs toLocalString vs cached Intl.NumberFormat

Script Preparation code:

var formatter = new Intl.NumberFormat("en-US");

Tests:

Intl.NumberFormat
var a = new Intl.NumberFormat("en-US").format("10000");
toLocalString
var a = "10000".toLocaleString("en-US");
Intl.NumberFormat With cached formatter
var a = formatter.format("10000");

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Intl.NumberFormat
toLocalString
Intl.NumberFormat With cached formatter

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Yandex Browser 25 on Mac OS X 10.15.7

View result in a separate tab

Test name	Executions per second
Intl.NumberFormat	85244.9 Ops/sec
toLocalString	34586104.0 Ops/sec
Intl.NumberFormat With cached formatter	4185153.8 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated 6 months ago):

LLMs can make mistakes. Check important info.

Let's break down the provided JSON and explain what is being tested.

**Benchmark Overview**

The benchmark compares three approaches for formatting numbers in JavaScript:

1. `Intl.NumberFormat`
2. `toLocaleString` method
3. Using a cached instance of `Intl.NumberFormat`

**Options Compared**

* `Intl.NumberFormat`: formats numbers using the Internationalization API, which provides support for locale-specific formatting.
* `toLocaleString` method: formats numbers based on the browser's built-in locale settings.
* Cached `Intl.NumberFormat`: uses a pre-cached instance of `Intl.NumberFormat` to avoid re-creating the formatter on each execution.

**Pros and Cons**

* `Intl.NumberFormat`:
	+ Pros: provides fine-grained control over formatting options, supports multiple locales, and can be more efficient than other methods for complex formatting.
	+ Cons: requires internationalization support in the browser, and may not work as expected in older browsers or those with limited locale data.
* `toLocaleString` method:
	+ Pros: easy to use and works well out of the box, but may not provide fine-grained control over formatting options.
	+ Cons: depends on the browser's built-in locale settings, which can vary between users and devices.
* Cached `Intl.NumberFormat`:
	+ Pros: avoids re-creating the formatter on each execution, making it faster than using a new instance for each test case.
	+ Cons: may not work if the cached instance is garbage collected or modified during the benchmark run.

**Library/Technology Used**

The `Intl.NumberFormat` API uses the ECMAScript Internationalization API (ECMA-402) to provide support for locale-specific formatting. The `toLocaleString` method relies on the browser's built-in locale settings, which are implemented using the same API.

**Special JavaScript Feature/Syntax**

None mentioned in this specific benchmark. However, it's worth noting that some browsers may have additional features or syntax for internationalization and localization that can be used with `Intl.NumberFormat`.

**Alternatives**

Other approaches for formatting numbers in JavaScript include:

* Using a library like Moment.js or Luxon, which provide more extensive formatting options.
* Implementing custom formatting logic using plain JavaScript.
* Using a template engine like Handlebars or Mustache to render formatted templates.

Keep in mind that the choice of approach depends on the specific requirements and constraints of your project.

Related benchmarks:

Intl.NumberFormat vs toLocalString vs cached Intl.NumberFormat (version: 0)

Comparing performance of: Intl.NumberFormat vs toLocalString vs Intl.NumberFormat With cached formatter

Created: 2 years ago by: Guest

Jump to the latest result

Intl.NumberFormat

toLocalString

Intl.NumberFormat With cached formatter

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 6 months ago):