Toggle navigation
MeasureThat
.net
Create a benchmark
Tools
Feedback
FAQ
Register
Log In
Intl.NumberFormat vs string
(version: 1)
Comparing performance of:
Intl.NumberFormat vs toLocalString
Created:
one year ago
by:
Guest
Go to the latest result
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>
Run tests (2)
Previous results
Fork
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
Embed
Embed Benchmark Result
<iframe src="https://measurethat.net/Embed?id=602360" width="100%" height="500px"></iframe>
toLocalString
133.2M/s
Intl.NumberFormat
32K/s
View exact numbers
Test name
Executions per second
✓
toLocalString
133,187,368 Ops/sec
Intl.NumberFormat
32,127 Ops/sec
Autogenerated LLM Summary
(model
gpt-4o-mini
, generated one year ago):
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
Number.toLocaleString vs Intl.NumberFormat
Number.toLocaleString vs Intl.NumberFormat vs Regex
Number.toLocaleString vs Intl.NumberFormat vs Regex2515
Number.toLocaleString vs Intl.NumberFormat (single instance)
NumberFormat
cached Number.toLocaleString vs Intl.NumberFormat vs Regex
Number.toLocaleString vs Intl.NumberFormat single instance
Number.toLocaleString vs Intl.NumberFormat single instance 2
Comments
Confirm delete:
Do you really want to delete benchmark?