Disabling pluralGenerator call in messageFormatter

[Setogit]

Context: pluralGenerator takes 40% of the time spent by messsageFormater in my use case. I'd like to support an option to disable (for perf) for my clients (i'm a client of jquery/globalize).

Is such an option available already? What's the downside of disabling prulalGenerator other than obvious "auto pluralization will be disabled"? Can i assume i can save 40% time by disabling it?

The second largest time is spent by runtimeBind ==> runtimeKey ==> stringHash 30%. It sounds like rquired.

Thanks!

[rxaviers]

Is this a client-side or server-side application?

[Setogit]

Client-side usage; Node.js-based CLI utility.

[rxaviers]

Let me clarify my question, are you using Globalize in client-side code or server-side? Does Globalize run on a user browser or in your servers?

[Setogit]

Not on a user browser.

[rxaviers]

Ok, thanks, so first let's align the big picture, then the fine tunings.

On server-side, you are generally able to initialize your formatters first and use later. The formatter creation usually takes 10x more time than its execution. Both hits you observed happen during the formatter creation, so it's a one time thing compared to the live long of the server-side. First questions, is your concern the load time of your server application or its run time? Where in your code do you create the formatters? Are creating the formatters every time you need them or are you caching them?

Now to the fine tunning...

Is such an option available already? What's the downside of disabling prulalGenerator other than obvious "auto pluralization will be disabled"? Can i assume i can save 40% time by disabling it?

The only "option" is not having the plural module loaded (code), but using CJS when you require('globalize') every modules are loaded. One "workaround" would be to load the pieces yourself (code).

The second largest time is spent by runtimeBind ==> runtimeKey ==> stringHash 30%. It sounds like rquired.

On server-side you definitely don't need it (given #470 isn't implemented and would optionally use it). There's no option to disable it, but ideas for disabling it are welcome. Perhaps a class attribute Globalize.runtimeSupport = false? That would increase the bytes on every function (for the check), so we really need to understand the benefit first.

[Setogit]

Thanks, @rxaviers. My answers to your biig-picture questions:

My use case is not on browser but a CLI-type utility written on Node.js, Usually, the CLI calls my package which calls your messageFormatter a few times, then exits. From your Globalize viewpoint, that's almost exactly like the example: https://github.com/rxaviers/globalize/blob/fix-398-runtime/examples/hello-world-node-npm/main.js#L34. Only major difference is in my use case, there is just one "console.log( like( 1 ) );"

My concern/goal is to maximize the user experience of that scenario which is like "one load time plus a few runtime overhead" as opposed to "one load time plus millions of run-time". In the latter case, the "one load-time overhead" is negligible, but for my scenario, it's not.

With that said, my questions are the following: My use case is equivalent to:

var path = "like";
console.log(Globalize.messageFormatter( path )(1));

and in the next Globalize.messageFormatter call, path will be different. Can separating formatter creation from execution help to improve my scenario experience? How can i separate?

[Setogit]

What if i replace this.pluralGenerator with no-op as follows? Would that disable plural generation? Is it safe? Any side effect?
===> [self answering] yes, a major side effect: number/currency formatting will stop working.

var myGlobalizeInstance = new Globalize ...;
myGlobalizeInstance.pluralGenerator = function(){};

[Setogit]

then, on the execution side, peg$parsechars and peg$parsechar are the two major player in my use case (not the example). Are there binary versions of them?