1549578 - Cache most recently used UDateTimePatternGenerator

Status: RESOLVED FIXED

(Core :: JavaScript: Internationalization API, enhancement, P1)

Description

[André Bargull [:anba]]

Per https://v8.dev/blog/intl (currently not reachable, alternative source: https://github.com/v8/v8.dev/blob/master/src/blog/intl.md), V8 improved the time needed to allocate of Intl objects (V8 benchmark: https://github.com/v8/v8/blob/master/test/js-perf-test/Intl/constructor.js). We're now slower for the Intl.DateTimeFormat allocation benchmark, because we don't cache the UDateTimePatternGenerator, but instead always create a new one in intl_patternForSkeleton. V8 is currently caching the pattern generators for all locales, which would mean for us storing up to 750 [1] UDateTimePatternGenerator instances. But I guess for most use cases it's sufficient to only store the most recently used instance, so I'm proposing to do only that for the time being.

[1] Object.keys(getSelfHostedValue("intl_DateTimeFormat_availableLocales")()).length returns 750.

Caching the most recent UDateTimePatternGenerator instance improves the following µ-benchmark from ~570ms to ~30ms for me:

function test() {
    var t = dateNow();
    for (var i = 0; i < 1000; ++i) {
        var dtf = new Intl.DateTimeFormat();
        dtf.resolvedOptions(); // instantiate lazily computed elements
    }
    print(dateNow() - t);
}

For comparison, V8 needs ~160ms for that µ-benchmark.

Comment 1

[André Bargull [:anba]]

Attachment: Bug 1549578: Cache most recently used UDateTimePatternGenerator in SharedIntlData. r=jwalden!

Comment 2

[Jeff Walden [:Waldo]]

With the requested tweaks to this so small, I went ahead and made them and queued this up for landing.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/075075cb0b88
Cache most recently used UDateTimePatternGenerator in SharedIntlData. r=jwalden

Comment 4

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/075075cb0b88