Benchmark: cached Intl.NumberFormat vs new Intl.NumberFormat vs Number 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
Number('10000').toLocaleString('en-US', { style: 'currency', currency: 'EUR' })

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: 8 months ago)

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

Browser/OS: Chrome 141 on Mac OS X 10.15.7

View result in a separate tab

cached Intl.NumberFormat

3.6M/s

toLocaleString

61K/s

new Intl.NumberFormat

59K/s

View exact numbers

Test name	Executions per second
✓ cached Intl.NumberFormat	3,576,587 Ops/sec
toLocaleString	60,950 Ops/sec
new Intl.NumberFormat	58,785 Ops/sec

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

LLMs can make mistakes. Check important info.

**Benchmark Overview**

The provided JSON represents a JavaScript microbenchmarking test case, specifically focused on comparing three different approaches for formatting currency values in JavaScript.

**Options Compared**

1. **Cached Intl.NumberFormat**: This approach creates a cached instance of the `Intl.NumberFormat` object with specific settings (style: 'currency', currency: 'EUR') and then uses it to format the value 10000.
2. **New Intl.NumberFormat**: This approach creates a new instance of the `Intl.NumberFormat` object with the same settings as above, but without caching, and then uses it to format the value 10000.
3. **Number toLocaleString**: This approach directly formats the number 10000 using the `toLocaleString()` method with locale 'en-US' and options { style: 'currency', currency: 'EUR' }.

**Pros and Cons of Each Approach**

1. **Cached Intl.NumberFormat**:
	* Pros:
		+ Can potentially be faster since it reuses an existing cached object.
		+ Reduces the overhead of creating a new instance of `Intl.NumberFormat`.
	* Cons:
		+ May not work as expected if the cached object is garbage collected or if multiple threads try to access the same object simultaneously.
2. **New Intl.NumberFormat**:
	* Pros:
		+ Clearly documented and well-maintained API.
		+ Provides more control over formatting options.
	* Cons:
		+ Creates a new instance of `Intl.NumberFormat` for each execution, which can be slower than reusing an existing object.
3. **Number toLocaleString**:
	* Pros:
		+ Simple and intuitive API.
	* Cons:
		+ May not provide the same level of control over formatting options as `Intl.NumberFormat`.
		+ Can be slower due to its direct method call.

**Library: Intl.NumberFormat**

The `Intl.NumberFormat` object is a part of the ECMAScript Internationalization API (ECMA-402). It provides a way to format numbers according to a specific locale and formatting style. In this benchmark, it's used to format currency values with specific settings.

**Special JS Features/Syntax**

None mentioned in this particular benchmark case. However, it's worth noting that some other JavaScript features or syntax might be involved in more complex benchmarks, such as:

* Async/await
* Promises
* Web Workers
* Customized or proprietary libraries

Keep in mind that each benchmarking test case is tailored to its specific focus and requirements.

**Alternatives**

Some alternative approaches for formatting currency values in JavaScript include:

1. Using a custom library like moment.js or numeral.js.
2. Utilizing a different API, such as the `locale` module (available in Node.js).
3. Implementing your own formatting logic using regular expressions or string manipulation methods.

These alternatives might provide different trade-offs between performance, complexity, and maintainability, depending on the specific use case and requirements.

cached Intl.NumberFormat vs new Intl.NumberFormat vs Number 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

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

cached Intl.NumberFormat vs new Intl.NumberFormat vs Number 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

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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

Related benchmarks

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