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

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

Autogenerated LLM Summary (model gemma2:9b, generated 27 days ago):

LLMs can make mistakes. Check important info.

This benchmark tests the performance of three different ways to format currency values using JavaScript:

**Options Compared:**

* **`cached Intl.NumberFormat`**:  A new `Intl.NumberFormat` object is created once and stored in the global window object (`window.a`). Subsequent calls to `.format()` on this cached instance are used.
* **`new Intl.NumberFormat`**: A new `Intl.NumberFormat` object is created for every call to `.format()`. This means a fresh object with all its formatting settings is instantiated each time. 
* **`toLocaleString`**: Uses the built-in `toLocaleString()` method directly on a string, providing currency formatting.

**Pros and Cons:**

* **`cached Intl.NumberFormat`**:
    * **Pro**:  Generally the fastest as the object instantiation overhead is done only once.
    * **Con**: Requires more memory to store the cached object.
* **`new Intl.NumberFormat`**:
    * **Pro**: Doesn't require pre-caching, so suitable if you need different formatting for various currencies or scenarios. 
    * **Con**:  Slower due to repeated object creation.
* **`toLocaleString`**:
    * **Pro**: Simplest syntax and potentially efficient for single uses.
    * **Con**: Can be slower than `cached Intl.NumberFormat` if used repeatedly.

**Other Considerations:**

* **Memory Usage**:  Caching an `Intl.NumberFormat` object can consume more memory, especially if you have many different formatting needs.

**Alternatives:**

While the benchmark focuses on native JavaScript methods, other libraries exist for currency formatting:

* **Moment.js**: A popular date and time library that also includes robust currency formatting features.
* **NumberJS**: Offers a variety of number manipulation utilities, including currency formatting.

Let me know if you'd like to explore any specific aspect in more detail!

Latest run results:

Run details: (Test run date: 21 days ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

Browser/OS: Chrome 130 on Windows

View result in a separate tab

Test name	Executions per second
cached Intl.NumberFormat	1600684.5 Ops/sec
new Intl.NumberFormat	50920.7 Ops/sec
toLocaleString	28146444.0 Ops/sec

Related benchmarks:

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: 2 years ago by: Guest

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 gemma2:9b, generated 27 days ago):