1968581 - Loading aeoneshop.com spends 8x as much time in NumberFormat code as in Chrome

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Markus Stange [:mstange]]

Broken out from bug 1963322:

Loading https://aeoneshop.com/ in Desktop Firefox spends a lot more time in NumberFormat code than it does in Chrome.

Firefox profile of currency: https://share.firefox.dev/4kiXx0K (7431 samples)
Chrome profile of currency: https://share.firefox.dev/4mtGASN (981 samples, 7.6x faster)

The currency function is defined as follows in https://aeoneshop.com/public/build/scripts/vendors.3023.b4c6f810f619bd652e3e.js :

                this.formats = {
                    number: function(e, t, n) {
                        return new Intl.NumberFormat(t,n).format(e)
                    },
                    currency: function(e, t, n) {
                        return new Intl.NumberFormat(t,te(te({}, n), {}, {
                            style: "currency"
                        })).format(e)
                    },
                    datetime: function(e, t, n) {
                        return new Intl.DateTimeFormat(t,te({}, n)).format(e)
                    },
                    relativetime: function(e, t, n) {
                        return new Intl.RelativeTimeFormat(t,te({}, n)).format(e, n.range || "day")
                    },
                    list: function(e, t, n) {
                        return new Intl.ListFormat(t,te({}, n)).format(e)
                    }
                },

To reproduce this, first go to the page, complete the captcha, and press the confirmation button ("START SHOPPING") in the dialog that's displayed. From then on, you can just navigate to https://aeoneshop.com/ normally.

Comparison report (if you have access): https://github.com/jrmuizel/js-profile-compare/blob/main/reports/aeoneshop-Bug1963322-BrowserWin-20250526.md

Comment 1

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

I wonder if Chrome is caching things; it's surprising that we're spending 4800 samples in icu_77::number::LocalizedNumberFormatter::formatImpl and they're spending 500 samples in icu_74::number::LocalizedNumberFormatter::formatImpl; either there's a big regression in ICU between 74 and 77, or somehow Chrome is calling this much less frequently.

André, any quick thoughts here? (feel free to decline)

Comment 2

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

:facepalm:

I didn't realize the Firefox profile is like 3x the length of the Chrome one. So that's certainly part of it.

Comment 3

[Markus Stange [:mstange]]

Both profiles were of a single load, I selected the "busy" range before the first idle gap where we started waiting for a timer to fire. So I hope they contain roughly the same amount of work, and the sample counts should be comparable.

Comment 4

[André Bargull [:anba]]

I don't see any performance difference when comparing currency formatting using the SM (central) and V8 (13.9.26) shells. Here's a simple test case using the Intl.NumberFormat options and Number values from the web site:

function f() {
  var xs = [0, 825000, 1178100, 535000, 1055400, 1254000, 1766200, 69000];
  var r = 0;
  var t = performance.now();
  for (var i = 0; i < 100000; ++i) {
    var nf = new Intl.NumberFormat("vi-VN", {style: "currency", currency: "VND"});
    r += nf.format(xs[i & 7]).length;
  }
  console.log(performance.now() - t, r);
}
for (let i = 0; i < 10; ++i) f();

Maybe it's worth checking that the currency function is really called the same time for both browsers and that the profiler measures the same number of calls to curreny?

---

Apart from that:
V8 has an optimisation to skip setting the numbering system when it's latn, whereas we're always setting the numbering system. And they also seem to omit default values for other options, whereas NumberFormatterSkeleton always constructs a full skeleton string. We could try if changing that improves performance.