1514851 - Number.prototype.toLocaleString is slow

Status: RESOLVED WORKSFORME

(Core :: JavaScript: Internationalization API, defect, P2)

Description

[Jason Orendorff [:jorendorff]]

function test(n) {
  let t0 = Date.now();
  for (let i = 0; i < n; i++) {
    someGlobalVar = i.toLocaleString('foo');
  }
  return Date.now() - t0;
}

On my macbook, test(30000) returns about 1000, i.e. it takes about a second to run. Maybe it's just me, but that seems slow; we can do about ten million calls to i.toString() in the same amount of time.

Is there work in toLocaleString that we should be caching?

Comment 1

[Jason Orendorff [:jorendorff]]

It's still slow if you use 'en-US' as the locale string.

Comment 2

[Jason Orendorff [:jorendorff]]

One reason to care about this is that Array.prototype.toLocaleString() does in fact call .toLocaleString on each element, so it might be an almost normal thing to have this method called thousands of times.

Comment 3

[Jason Orendorff [:jorendorff]]

This has real-world consequences: toLocaleString is so slow that using it in about:memory caused serious performance problems (bug 1517354) that were resolved by ripping it out.

Comment 4

[Nicholas Nethercote [inactive]]

bug 15173540

There's a typo in that bug number, it should be bug 1517354.

Comment 5

[Jeff Walden [:Waldo]]

Attachment: test.html

Comment 6

[Jeff Walden [:Waldo]]

Attachment: Profile

https://perfht.ml/31GU6ci

Looks like 77% of this is in js::intl_FormatNumber unsurprisingly. (And a further 7% in one of the other leaves, not sure why precisely.) Within there,

• 27% in unum_open
• 19% in PartitionNumberFormat and most of that in unum_formatDoubleForFields
• 18% in js::intl::GetInternalsObject
• 12% in unum_setAttribute (!) corresponding to icu::DecimalFormat::setRoundingMode (wat)

Some portions of overhead in there that we could eliminate for sure. Other bits in there are in ICU. We aren't entirely helped by jumping in and out of self-hosted code frequently, it appears, perhaps as a general concern.

A fair number of things that could be investigated here, for sure.

Comment 7

[Matthew Gaudet (he/him) [:mgaudet]]

Not sure what would be a reasonable value here, but my experimentation suggests this is good enough

Here's a profile of Jason's test case in the shell run with 300,000 iterations:

https://share.firefox.dev/4cd0JH0

icu_73::(anonymous namespace)::DecFmtSymDataSink::put is the highest consumer of time now, and that's only 2.5%