Experimental Workload: Intl#146
Conversation
✅ Deploy Preview for webkit-jetstream-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@iainireland this might be interesting too for mozilla, seems like your implementation is fairly efficient: spidermonkey > jsc > v8 |
|
Looks like we get slightly different results perf platform :/. Looking into it. |
|
We might have to skip Intl.RelativeTimeFormat due to interop issues, SpiderMonkey and V8 agree, but JSC does have some different values. Examples:
|
|
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. |
|
Thanks for the insights. I think that's fair to not include this in the final score then if the behavior is not specced properly. I'd like to keep this as non-default workload for now then, I think this is still going to be interesting for engineers to optimise this in a realistic scenario. Independent of this, I'm now curious if there are any plans to improve the interop situation here long-term? In my naive understanding I would expect that most JS APIs work consistently across platforms. |
|
Overall LGTM.
I think TC-39 intentionally left this up to implementations. IIRC, one specific case was for embedded devices where there may not be enough disk space to hold every locale. Also, since most engines/TC-39 don't own ICU the exact localization is implementation defined. |
|
Ok, then let's definitely keep this disabled. Not sure – should there ever be a fixed agreement on a set of locales we could reconsider this. |
kmiller68
left a comment
kmiller68
left a comment
There was a problem hiding this comment.
Based on some internal discussion maybe we should add an Intl.Segmenter test too. We can file an issue for that later though.
|
SG, filed #181 to keep track of this. |
3 participants
This could potentially replace the old datetime formatting workloads.
The workload stress tests the following Intl APIs:
I've gone with a fairly random choice of locals before spending more time on getting a more representative list.