Benchmark: toLocaleDateString()

Script Preparation code:

var date = new Date();
var intl = new Intl.DateTimeFormat(undefined, {weekday: 'short', day: 'numeric', month: 'short'});

Tests:

toLocaleDateString()
var str = date.toLocaleDateString(undefined, {weekday: 'short', day: 'numeric', month: 'short'});
Intl.DateTimeFormat()
var str2 = new Intl.DateTimeFormat(undefined, {weekday: 'short', day: 'numeric', month: 'short'}).format(date);
Intl.DateTimeFormat() cached
var str3 = intl.format(date);

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
toLocaleDateString()
Intl.DateTimeFormat()
Intl.DateTimeFormat() cached

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 27 days ago):

LLMs can make mistakes. Check important info.

Measuring the performance of different approaches to formatting dates in JavaScript.

The benchmark tests three main options:

1. **toLocaleDateString()**: This method is part of the JavaScript `Date` object and uses the browser's locale settings to format the date. It's a simple and widely supported approach, but its performance can vary depending on the browser and locale.
2. **Intl.DateTimeFormat() without caching**: This method uses the Internationalization API to format dates according to a specific locale. Without caching, it creates a new instance of `Intl.DateTimeFormat` for each execution, which can lead to slower performance compared to caching.
3. **Intl.DateTimeFormat() with caching**: This method caches the formatted date instance, so subsequent executions use the cached result instead of recreating the format object.

Pros and Cons:

* **toLocaleDateString()**:
	+ Pros: Simple, widely supported, and fast in most browsers.
	+ Cons: May not produce consistent results across different locales and browsers.
* **Intl.DateTimeFormat() without caching**:
	+ Pros: More control over formatting options and locale settings.
	+ Cons: Slower performance due to the creation of new instances.
* **Intl.DateTimeFormat() with caching**:
	+ Pros: Faster performance, as it reuses cached format objects.
	+ Cons: Requires more memory to store the cache.

The benchmark results show that:

* `Intl.DateTimeFormat()` with caching is the fastest approach, with an average execution rate of 8890.87 executions per second.
* `toLocaleDateString()` is the second-fastest option, with an average execution rate of 48130.21 executions per second.
* `Intl.DateTimeFormat()` without caching is the slowest option, with an average execution rate of 8424.84 executions per second.

The `Date` object's locale settings are used to determine the format options. For example, in the first benchmark definition, `undefined` is passed as the locale argument, which means the browser will use its default locale setting. The `Intl.DateTimeFormat()` method uses a specific locale, such as `'en-US'`, which determines the formatting options.

Other alternatives include using other localization APIs or libraries that provide more fine-grained control over date formatting, but are likely to incur performance overhead.

Latest run results:

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

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36

Browser/OS: Chrome 89 on Mac OS X 11.2.2

View result in a separate tab

Test name	Executions per second
toLocaleDateString()	8890.9 Ops/sec
Intl.DateTimeFormat()	8424.8 Ops/sec
Intl.DateTimeFormat() cached	481302.4 Ops/sec

Related benchmarks:

toLocaleDateString() (version: 0)

Comparing performance of: toLocaleDateString() vs Intl.DateTimeFormat() vs Intl.DateTimeFormat() cached

Created: 4 years ago by: Guest

Jump to the latest result

toLocaleDateString()

Intl.DateTimeFormat()

Intl.DateTimeFormat() cached

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 27 days ago):