Benchmark: Intl.NumberFormat vs string

Script Preparation code:

const priceCurrency = "CZK"
const price = "121.0"

Tests:

Intl.NumberFormat
return new Intl.NumberFormat('cs-CZ', { style: 'currency', currency: priceCurrency , minimumFractionDigits: 0 }).format(Number(price));
toLocalString
return `${priceCurrency} ${price}`;

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Intl.NumberFormat
toLocalString

Fastest: N/A

Slowest: N/A

Latest run results:

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

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

Browser/OS: Chrome 134 on Windows

View result in a separate tab

Test name	Executions per second
Intl.NumberFormat	32126.8 Ops/sec
toLocalString	133187368.0 Ops/sec

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

LLMs can make mistakes. Check important info.

This benchmark compares two different approaches for formatting a monetary value in the Czech koruna (CZK) based on a given price string. The key options being tested are:

1. **Intl.NumberFormat**: A built-in JavaScript internationalization API designed for formatting numbers based on locale-specific conventions. This approach is notably more versatile and powerful, as it can handle different locales, currencies, and formatting options such as minimum or maximum fraction digits, currency display styles, etc.

2. **Template Literal Formatting**: A straightforward method that uses template literals (backticks) to concatenate the currency with the price directly. This creates a simple string representation of the monetary value without any localization or formatting.

### Pros/Cons of Each Approach:

#### Intl.NumberFormat
**Pros:**
- **Localization**: Automatically formats numbers according to localization standards, taking into account currency symbols and placement (e.g., in certain cultures the currency symbol is placed before the number, while in others it's placed after).
- **Flexibility**: Can easily adapt to different formatting requirements (e.g., controlling the number of decimal places).
- **Readability**: Results in a more human-friendly output for users, making it suitable for applications that require international users.

**Cons:**
- **Performance**: As seen in the benchmark results, this approach is significantly slower due to additional processing involved in formatting (executions per second: ~73,016).
- **Complexity**: While it offers extensive options, it may not be necessary for all applications, especially if simple formatting suffices.

#### Template Literal Formatting
**Pros:**
- **Performance**: Far quicker in execution (executions per second: ~309,729), making it more suitable for scenarios where performance is critical, such as real-time applications or in high-frequency loops.
- **Simplicity**: A straightforward approach that is easy to understand and implement with minimal overhead.

**Cons:**
- **Lack of Localization**: This method does not take into account cultural differences in formatting. For example, it might not correctly format numbers in different locales (e.g., thousands separators).
- **Static Output**: It lacks flexibility in terms of future modifications if the formatting rules need to change.

### Other Considerations:
- **Use Cases**: For applications that target a global audience or require flexibility in numeric output, `Intl.NumberFormat` is generally preferred despite its performance cost. On the other hand, applications that prioritize performance and have controlled input might find the template literal sufficient.
  
- **Alternatives**: Other alternatives could include:
  - **Number.toLocaleString()**: Another built-in method that provides locale-aware number formatting similar to `Intl.NumberFormat` but is invoked directly on the number object.
  - **Custom Formatting Libraries**: Libraries such as `Numeral.js` or `accounting.js`, which provide customized number formatting capabilities.

In conclusion, when choosing between these approaches, it's essential to evaluate the context of use, required functionality, and performance constraints adequately to select the most appropriate method for number formatting in your application.

Related benchmarks:

Intl.NumberFormat vs string (version: 1)

Comparing performance of: Intl.NumberFormat vs toLocalString

Created: one year ago by: Guest

Jump to the latest result

Intl.NumberFormat

toLocalString

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

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