Benchmark: cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString currency

Tests:

cached Intl.NumberFormat
window.a = window.a || new Intl.NumberFormat('en-US', { style: 'currency', currency: 'EUR' }); window.a.format("10000")
new Intl.NumberFormat
new Intl.NumberFormat('en-US', { style: 'currency', currency: 'EUR' }).format('10000');
toLocaleString
"10000".toLocaleString('en-US', { style: 'currency', currency: 'EUR' })

Historical Performance Data aggregated from 29 community runs

Desktop Results:

Chrome 22 runs

toLocaleString

28.4M/s

cached Intl.NumberFormat

2.7M/s

new Intl.NumberFormat

50K/s

Fastest: toLocaleString (562.6x faster)

View exact numbers

✓ toLocaleString: 28,355,172 ops/sec
• cached Intl.NumberFormat: 2,689,250 ops/sec
• new Intl.NumberFormat: 50,402 ops/sec

Firefox 7 runs

toLocaleString

955.1M/s

cached Intl.NumberFormat

1.3M/s

new Intl.NumberFormat

33K/s

Fastest: toLocaleString (28523.6x faster)

View exact numbers

✓ toLocaleString: 955,082,112 ops/sec
• cached Intl.NumberFormat: 1,331,866 ops/sec
• new Intl.NumberFormat: 33,484 ops/sec

Results show median performance across all community submissions. Run this benchmark yourself to verify on your device.

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
cached Intl.NumberFormat
new Intl.NumberFormat
toLocaleString

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 147 on Mac OS X 10.15.7

View result in a separate tab

toLocaleString

5.5M/s

cached Intl.NumberFormat

2.4M/s

new Intl.NumberFormat

13K/s

View exact numbers

Test name	Executions per second
✓ toLocaleString	5,495,398 Ops/sec
cached Intl.NumberFormat	2,363,307 Ops/sec
new Intl.NumberFormat	13,140 Ops/sec

Autogenerated LLM Summary (model llama3.1:latest, generated one year ago):

LLMs can make mistakes. Check important info.

Let's break down what is being tested here.

**Benchmark Overview**

The provided JSON represents a benchmark test case on the MeasureThat.net platform, which compares the performance of three different approaches to formatting numbers in JavaScript:

1. **Cached Intl.NumberFormat**: This approach creates an instance of `Intl.NumberFormat` once and caches it for reuse.
2. **New Intl.NumberFormat**: This approach creates a new instance of `Intl.NumberFormat` every time it's needed.
3. **toLocaleString**: This approach uses the `toLocaleString()` method to format numbers.

**What is being tested?**

The test case is measuring how many times each approach can format numbers per second (ExecutionsPerSecond) on a Chrome browser running on Linux Desktop.

**Options Compared**

Here are the pros and cons of each approach:

1. **Cached Intl.NumberFormat**:
	* Pros: Since the `Intl.NumberFormat` instance is created once, it can reuse its formatting logic, which might be efficient for multiple format requests.
	* Cons: However, if the formatting options change (e.g., currency), a new instance needs to be created, which could lead to performance issues if not properly handled.
2. **New Intl.NumberFormat**:
	* Pros: Each time a new instance is needed, it can reflect any changes in formatting options (e.g., currency) without affecting previous instances.
	* Cons: Creating a new instance every time can be slower and more resource-intensive than reusing an existing one.
3. **toLocaleString**:
	* Pros: This method avoids the overhead of creating a dedicated `Intl.NumberFormat` instance and uses native string manipulation methods instead.
	* Cons: However, it might not provide the same formatting options or customization as using `Intl.NumberFormat`.

**Other Considerations**

When choosing an approach, consider factors like:

* Frequency of format requests
* Changes in formatting options (e.g., currency)
* Resource constraints (e.g., performance, memory)

**Special JS Feature or Syntax Used**

In this test case, the `Intl.NumberFormat` API is used to format numbers according to international standards. This is a feature supported by modern browsers and Node.js.

**Library Used**

No external library is used in these benchmark tests; only built-in JavaScript APIs are employed.

**Alternatives**

Other alternatives for formatting numbers include:

* Using a custom formatting function
* Utilizing a third-party library (e.g., numeral.js, accounting.js)
* Employing a different string manipulation method (e.g., regex)

Each of these alternatives has its pros and cons, which might make them more or less suitable depending on the specific use case.

cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString currency (version: 0)

Comparing performance of: `cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString`

Created: 4 years ago by: Guest

Go to the latest result

cached Intl.NumberFormat

new Intl.NumberFormat

toLocaleString

Historical Performance Data aggregated from 29 community runs

Desktop Results:

Chrome 22 runs

Firefox 7 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.1:latest, generated one year ago):

cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString currency (version: 0)

Comparing performance of: cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString

Created: 4 years ago by: Guest

Go to the latest result

cached Intl.NumberFormat

new Intl.NumberFormat

toLocaleString

Historical Performance Data aggregated from 29 community runs

Desktop Results:

Chrome 22 runs

Firefox 7 runs

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.1:latest, generated one year ago):

Related benchmarks

Comparing performance of: `cached Intl.NumberFormat vs new Intl.NumberFormat vs toLocaleString`