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

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' })

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

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

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

View result in a separate tab

Test name	Executions per second
cached Intl.NumberFormat	4559317.5 Ops/sec
new Intl.NumberFormat	60884.7 Ops/sec
toLocaleString	63663.7 Ops/sec

Autogenerated LLM Summary (model gpt-4o-mini, generated 4 months ago):

LLMs can make mistakes. Check important info.

The benchmark in question evaluates the performance of three different methods of formatting numbers as currency in JavaScript, specifically using locale settings for the Euro currency. Here’s an analysis of the test cases included in the benchmark and the libraries/syntax used:

### Test Cases Evaluated

1. **Cached Intl.NumberFormat**
   - **Definition:** `window.a = window.a || new Intl.NumberFormat('en-US', { style: 'currency', currency: 'EUR' }); window.a.format(10000);`
   - **Approach:** This test case caches an instance of `Intl.NumberFormat` in a global variable `window.a`, so that the expensive initialization only happens once. This cached formatter is then used to format the number 10000 as currency.
   - **Pros:** Reduces the overhead of creating the formatter multiple times, leading to significantly faster performance on repeated calls.
   - **Cons:** Requires careful management of the cache; potential issues if the formatting options need to change, as those would require a new instance.

2. **New Intl.NumberFormat**
   - **Definition:** `new Intl.NumberFormat('en-US', { style: 'currency', currency: 'EUR' }).format(10000);`
   - **Approach:** This instance creates a new `Intl.NumberFormat` object each time it is called to format the number. The formatting options are specified each time.
   - **Pros:** Provides flexibility since each call can potentially have different options or locales.
   - **Cons:** Higher performance overhead due to the constant instantiation of the formatter, making it slower especially when formatting numbers multiple times.

3. **toLocaleString**
   - **Definition:** `(10000).toLocaleString('en-US', { style: 'currency', currency: 'EUR' })`
   - **Approach:** This utilizes the native `toLocaleString()` method on the number object, passing the locale and options for currency formatting.
   - **Pros:** It is generally straightforward to use and does not require explicit management of formatter instances. It's built into the Number prototype.
   - **Cons:** Performance tends to be slower than a cached `Intl.NumberFormat`, especially if many format calls are being made, as it might create new objects internally.

### Benchmark Results Analysis

Based on the benchmark results:

- **Cached Intl.NumberFormat** achieved the highest performance with approximately 4,559,317 executions per second, demonstrating the efficiency gained through caching mechanism.
- **toLocaleString** produced about 63,663 executions per second, which shows that while convenient, it does not compare well in terms of raw performance for multiple calls.
- **New Intl.NumberFormat** was the slowest at approximately 60,884 executions per second, highlighting the expense of creating a new formatter for each call.

### Other Considerations

- **Intl.NumberFormat**: The `Intl` object and its `NumberFormat` method are part of the ECMAScript Internationalization API, which provide language-sensitive number and date formatting. This API facilitates proper localization for different regions.
- **Browser Compatibility**: Most modern browsers support `Intl`, but older browsers may not, which can influence decisions on whether to use it in production code.
- **Performance vs. Flexibility Trade-off**: If an application needs to format numbers differently in various situations (e.g. dynamic locale changes), using `new Intl.NumberFormat` might be necessary despite the performance hit. In situations where performance is critical, caching the formatter or using `toLocaleString` judiciously might be preferred.
  
### Conclusion

In summary, the benchmark illustrates the performance trade-offs among different methods of formatting currency in JavaScript. For scenarios requiring high performance with consistent formatting options, reusing `Intl.NumberFormat` via caching is clearly advantageous. Conversely, if flexibility is paramount, using `new Intl.NumberFormat` may be warranted, even at the cost of slower execution times. `toLocaleString`, while convenient and easy to use, should be assessed against performance needs in cases of high-frequency formatting.

Related benchmarks:

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

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

Created: 4 months ago by: Registered User

Jump to the latest result

cached Intl.NumberFormat

new Intl.NumberFormat

toLocaleString

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model gpt-4o-mini, generated 4 months ago):