New Workload: Intl

[camillobruni]

This could potentially replace the old datetime formatting workloads.
The workload stress tests the following Intl APIs:

• DateTimeFormat
• ListFormat
• RelativeTimeFormat
• NumberFormat
• PluralRules

I've gone with a fairly random choice of locals before spending more time on getting a more representative list.

[netlify]

✅ Deploy Preview for webkit-jetstream-preview ready!

Name	Link
🔨 Latest commit	9377081
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-jetstream-preview/deploys/68adcfbbadfe740008d03b0b
😎 Deploy Preview	https://deploy-preview-146--webkit-jetstream-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[camillobruni]

@iainireland this might be interesting too for mozilla, seems like your implementation is fairly efficient: spidermonkey > jsc > v8

[camillobruni]

Looks like we get slightly different results perf platform :/. Looking into it.

[camillobruni]

We might have to skip Intl.RelativeTimeFormat due to interop issues, SpiderMonkey and V8 agree, but JSC does have some different values.

Examples:

• missing spaces:

• Spanish: en vs dentro de)

• There are further issues, now with v8, for some units it changes the decimal point:

[Constellation]

I have a concern about this benchmark since it ends up just measuring ICU performance. ICU version and Intl format is arbitrary, and the output / behavior / customization is not standardized by the spec (ECMA-402 offers significant amount of freedom to the implementation). So it does not become apple-to-apple comparison.

If the input => output is defined by ECMA-402, and offering the freedom on how to implement these conversion, I think adding them as a benchmark makes sense. However, ECMA-402 does not specify what output we will get, so measuring these performance on each engine ends up measuring completely different workload under the same name.

For example, it is possible that we can make the code faster by stripping all of locales and just having en_US. But I don't think that's the direction JetStream should encourage. Also each platform tends to customize (even adding some special code in some cases) ICU to offer their platform-consistent behavior, so each one is doing different things and generating different outputs.

Apple ICU is heavily modified to make the i18n results consistent to Apple HIG and the rest of the platform. Google Chrome's bundled ICU is customizing locale's behavior (e.g. using latin numbers for ar_AE). Firefox ICU is stripping many locales to reduce the payload size. So customizations and behavior difference is already real. I don't think comparing the performance without caring the output difference makes sense.