Globalization API Feedback - moar!

Nebojša Ćirić cira at
Fri Dec 2 10:20:05 PST 2011

I know this is related to the actual implementation, but there are some
things we won't be able to avoid if we go with new (functional) API. If
performance penalty is acceptable then we should proceed with the

1. Single format/comparison operation - performance should be mostly the
same for both (most of the time would go into creating the support object -
say ICU collator)
2. Multiple format/comparison invocations - performance should be on the
side of object like API, the question is just how much
  2a. Both approaches have to create supporting object and process options,
but object approach does that only once
  2b. Functional approach would have to cache objects, which should help,
but in that case it would need to generate hash keys from given options

I wrote a short benchmark (JS code only) to see how much hashing influences
the performance. Please take a look at the results and the code (any
optimization hints are welcome).


Code (formatter is intentionally trivial in both cases):

01. децембар 2011. 11.53, Brendan Eich <brendan at> је написао/ла:

> On Nov 30, 2011, at 11:37 PM, Brendan Eich wrote:
> On Nov 30, 2011, at 10:25 PM, Anton Yatsenko wrote:
> In case I've missed point — sorry.
> There are several points. How one gets the Globalization "module" is one,
> but the bigger points at issue involve API parameterization, overhead, and
> style issues.
> Also, critically (Shawn Steele's latest post, cited in full below, hit
> this point) "support inference" or in general, whether and how fallback
> works.
> /be
> Furthermore some implementations succeed for *any* input locale.  In those
> cases DateTimeFormat could succeed for any input RFC4646 string.  Many of
> those may fall back to non-specific data, but it is possible for
> getSupportedLocales to succeed for all of those.
> It might be more practical to have a "getExplicitLocales" for the locales
> that the system has explicit information for, but I'm not sure how that'd
> be helpful.  In Mark's case "de" might be the explicit locale that supports
> the collator but your application would somehow have to infer that "de"
> might also be useful for de-*.  Furthermore, if Mark had a "de" collator,
> and generic Number/DateTimeFormats, but additional specific de-AT and de-CH
> Number formats, then he might return de, de-AT, and de-CH, but you'd still
> be left inferring that de supported de-DE by default (not necessarily a
> good assumption, particularly across implementations).
> -Shawn
>  
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list