Benchmark: Intl.NumberFormat vs toLocalString vs Custom Format vs Pre-created Intl formatter

Script Preparation code:

function formatUSD(a) {
	return '$' + a;
}

var formatIntlUSD = new Intl.NumberFormat("en-US", { style: 'currency', currency: 'USD' });

Tests:

Intl.NumberFormat
var a = new Intl.NumberFormat("en-US", { style: 'currency', currency: 'USD' }).format("10000");
toLocalString
var a = (10000).toLocaleString("en-US", { style: 'currency', currency: 'USD' });
Custom Formatter
var a = formatUSD("10000");
Pre-created Intl formatter
var a = formatIntlUSD.format("10000");

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Intl.NumberFormat
toLocalString
Custom Formatter
Pre-created Intl formatter

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: one month ago)

User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

Browser/OS: Chrome 146 on Linux

View result in a separate tab

Test name	Executions per second
Intl.NumberFormat	58125.3 Ops/sec
toLocalString	59794.7 Ops/sec
Custom Formatter	172110176.0 Ops/sec
Pre-created Intl formatter	2750228.2 Ops/sec

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

LLMs can make mistakes. Check important info.

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

**Benchmark Overview**

The benchmark compares the performance of four approaches to format numbers with currency symbols:

1. Using `Intl.NumberFormat` API
2. Using `toLocaleString()` method
3. Creating a custom formatter function
4. Using a pre-created `Intl.NumberFormatter` instance

**Library and Its Purpose**

* `Intl.NumberFormat`: This is an Internationalization (I18N) API provided by the JavaScript Standard Library. It allows developers to format numbers with locale-specific formatting options, such as currency symbols.
* `toLocaleString()` method: This method returns a string representation of a number in the user's default locale.

**Test Cases**

The benchmark includes four test cases:

1. **Intl.NumberFormat**: Creates an instance of `Intl.NumberFormat` and uses it to format the number 10,000 with currency symbol. The expected output is "$10,000".
2. **toLocalString() method**: Uses the `toLocaleString()` method to format the number 10,000 in the user's default locale. The expected output will depend on the user's locale settings.
3. **Custom Formatter**: Creates a custom function `formatUSD` that returns a formatted string with currency symbol and number. In this case, the custom function simply concatenates the dollar sign with the input number.
4. **Pre-created Intl formatter**: Creates an instance of `Intl.NumberFormatter` (not `NumberFormat`, which is incorrect) and uses it to format the number 10,000 with currency symbol.

**Options Compared**

The benchmark compares the performance of these four approaches in terms of:

* Number of executions per second
* Execution time (not explicitly measured, but implied by the raw UA string and execution count)

**Pros and Cons of Each Approach**

Here's a brief overview of each approach:

1. **Intl.NumberFormat**: Pros:
	* Standardized API for internationalization
	* Supports multiple locales
	* Can be customized with options (style, currency, etc.)
Cons:
	* May have slower performance compared to custom or pre-created solutions
2. **toLocaleString() method**: Pros:
	+ Fast and lightweight
	+ Uses user's default locale settings
Cons:
	+ Format output may vary depending on user's locale settings
3. **Custom Formatter**: Pros:
	+ Can be optimized for specific use cases
	+ Simple to implement (just a function)
Cons:
	+ May require manual handling of formatting options (style, currency, etc.)
4. **Pre-created Intl formatter** (Note: This is likely a typo and should be `Intl.NumberFormat`): Pros:
	+ Can take advantage of optimizations provided by the library
	+ Simplifies code for common use cases

**Other Considerations**

* When choosing an approach, consider factors such as performance requirements, internationalization needs, and ease of maintenance.
* For large-scale applications or complex formatting scenarios, custom or pre-created solutions may be more suitable.

**Alternatives**

If you need alternative approaches, here are a few options:

1. **DOM-based libraries**: For customizing the output format, consider using a library like Moment.js or XLSX.
2. **Pre-built libraries**: There are many third-party libraries available for formatting numbers with currency symbols, such as currencyFormatter or IntlNumberFormatter.
3. **Browser-specific solutions**: Some browsers have built-in APIs or extensions that can simplify number formatting (e.g., Chrome's `formattedValue` API).

Keep in mind that the best approach will depend on your specific use case and requirements.

Related benchmarks:

Intl.NumberFormat vs toLocalString vs Custom Format vs Pre-created Intl formatter (version: 0)

Comparing performance of: Intl.NumberFormat vs toLocalString vs Custom Formatter vs Pre-created Intl formatter

Created: 3 years ago by: Guest

Jump to the latest result

Intl.NumberFormat

toLocalString

Custom Formatter

Pre-created Intl formatter

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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