Benchmark: cached Number.toLocaleString vs Intl.NumberFormat

HTML Preparation code:

<script>
    function toLocaleString(number = NaN, decimals) {
        return number.toLocaleString('en-US', {
            maximumFractionDigits: decimals,
            minimumFractionDigits: decimals,
        });
    };

    const numberFormatter = new Intl.NumberFormat('en-US');
    const formatCache = new Map();

    function formatNumber(number = NaN, decimals) {
        // Handle NaN early to avoid unnecessary processing
        if (isNaN(number)) {
            return 'NaN';
        }

        // Use cached formatter if decimals are undefined
        if (decimals === undefined) {
            return numberFormatter.format(number);
        }

        // Cache and reuse formatters for specific decimal places
        let formatter = formatCache.get(decimals);
        if (!formatter) {
            formatter = new Intl.NumberFormat('en-US', {
                maximumFractionDigits: decimals,
                minimumFractionDigits: decimals,
            });
            formatCache.set(decimals, formatter);
        }

        return formatter.format(number);
    };
</script>

Script Preparation code:

const formatter = new Intl.NumberFormat(undefined, {
    style: 'currency',
    currency: 'RUB',
});

Tests:

Number.toLocaleString
toLocaleString(1000000, 1); toLocaleString(1000000, 2); toLocaleString(1000000, 10); toLocaleString(1000000, 8); toLocaleString(1000000, 12);
Intl.NumberFormat
formatNumber(1000000, 1); formatNumber(1000000, 2); formatNumber(1000000, 10); formatNumber(1000000, 8); formatNumber(1000000, 12);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Number.toLocaleString
Intl.NumberFormat

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 3 months ago)

User agent: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) SamsungBrowser/28.0 Chrome/130.0.0.0 Mobile Safari/537.36

Browser/OS: Chrome Mobile 130 on Android

View result in a separate tab

Test name	Executions per second
Number.toLocaleString	6190.3 Ops/sec
Intl.NumberFormat	305705.9 Ops/sec

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

LLMs can make mistakes. Check important info.

The benchmark defined in the provided JSON compares the performance of two approaches for formatting numbers in JavaScript: using the built-in `Number.toLocaleString()` method and utilizing the `Intl.NumberFormat` object with a caching mechanism.

### What is Tested

1. **`Number.toLocaleString`:**
   - This is a method that formats a number according to the locale settings and the options provided. It takes parameters such as the locale string (e.g., 'en-US') and an options object that can specify settings like the number of decimal places.
   - The benchmark tests this method for a fixed number (`1000000`) with varying decimal precision (1, 2, 10, 8, and 12).

2. **`Intl.NumberFormat`:**
   - This is part of the ECMAScript Internationalization API, which provides a way to format numbers according to locale and formatting options. It is generally more flexible than `toLocaleString`, particularly for caching and reusing formatters.
   - The benchmark tests a custom function `formatNumber`, which caches the created formatter instances in a `Map`. The same fixed number (`1000000`) is formatted with similar decimal precision (1, 2, 10, 8, and 12).

### Pros and Cons

**1. `Number.toLocaleString`:**
   - **Pros:**
     - Simple and straightforward method to use if you need to format numbers for a specific locale.
     - No additional setup is required; it works out of the box.
   - **Cons:**
     - Performance can degrade if called repeatedly with different formatting options, as it creates a new formatter each time.
     - Limited control over advanced formatting behaviors compared to `Intl.NumberFormat`.

**2. `Intl.NumberFormat`:**
   - **Pros:**
     - More efficient when formatting the same number with different decimal places, as it allows for reusing the same formatter instance.
     - Well-suited for scenarios where multiple formats of the same number are needed, reducing overhead.
   - **Cons:**
     - Slightly more complex to implement due to the need for setup and caching logic.
     - May require a bit more understanding of the Internationalization API for newcomers.

### Other Considerations

- **Caching Mechanism:** 
  The use of a `Map` to cache formatters in `Intl.NumberFormat` allows the benchmark to avoid the overhead of creating a new formatter every time a number is formatted with the same decimal places. This technique enhances performance in scenarios where the formatting function is called multiple times with repeated decimal settings.

### Benchmark Results

The benchmark results show a significant difference in performance:
- `Intl.NumberFormat` achieved an execution speed of approximately **647,574 executions per second**.
- `Number.toLocaleString` performed at only about **15,426 executions per second**.

These results illustrate that `Intl.NumberFormat`, particularly with the caching strategy, is far more efficient for number formatting, especially in scenarios requiring multiple calls with different decimal settings.

### Alternatives

- **Native JavaScript Formatting:** Other than `toLocaleString` and `Intl.NumberFormat`, developers might implement custom formatting functions using string manipulation; however, this could be less efficient and not locale-sensitive.
- **Third-party Libraries:** Libraries like `numeral.js` or `accounting.js` provide additional formatting functionalities but may not have the same performance benefits as the built-in options when not optimized.
- **Performance Libraries:** For applications requiring extensive numerical formatting, libraries designed for performance (e.g., `fast-number-format`) could be considered, but again, developers should measure performance against built-in options.

In summary, for number formatting in JavaScript, leveraging the `Intl.NumberFormat` approach, particularly with a caching strategy, offers better performance and flexibility compared to the built-in `Number.toLocaleString` method.

Related benchmarks:

cached Number.toLocaleString vs Intl.NumberFormat (version: 1)

Comparing performance of: Number.toLocaleString vs Intl.NumberFormat

Created: 4 months ago by: Registered User

Jump to the latest result

Number.toLocaleString

Intl.NumberFormat

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):