Memory/Perf progress on porting Settings to l20n.js

[Zibi Braniecki]

I got Settings to load properly, they're the opposite of FM radio. FM radio is localizing a single entity during launch. Settings are localizing above 100 before firstPaint.

The magic? The memory overhead of l20n.js over l10n.js is *exactly* the same. ~150kb.

That's a really good news because it means that it doesn't scale with data, it shouldn't affect default vs. non-default and the whole optimization work should go into the init codework in l20n.js that I already profiled pretty well.

I'm going to start doing that tomorrow. My plan is to take each major chunk of code that census shows as a major memory retenier (getMeta, plurals, pseudo, io.load) and try to optimize it and see the impact on raptor on FM and Settings.
If I get a win on both, I submit a patch.

Also, performance wise Settings with l10n.js and l20n.js are exactly on par. That's another great news. I still think there's room to improve l20n.js, but it seems that the baseline is there.

I think we should start pushing a bit harder on moving apps to l20n.js soon. I plan to submit a patch for Settings next week, I assume Stas is working on SMS, I think Homescreen/Music/Contacts will come next and I may want to move the trio of Video/Gallery/Camera in 2.5 window as well.

zb.

[Staś Małolepszy]

On Wed, Aug 19, 2015 at 9:07 PM, Zibi Braniecki <
zbigniew....@gmail.com> wrote:

> I got Settings to load properly, they're the opposite of FM radio. FM
> radio is localizing a single entity during launch. Settings are localizing
> above 100 before firstPaint.
>
> The magic? The memory overhead of l20n.js over l10n.js is *exactly* the
> same. ~150kb.
>

That's good to know. And I feel like we have a pretty good idea of where
about half of that extra memory is used, right? The module system?

> That's a really good news because it means that it doesn't scale with
> data, it shouldn't affect default vs. non-default and the whole
> optimization work should go into the init codework in l20n.js that I
> already profiled pretty well.
>
> I'm going to start doing that tomorrow. My plan is to take each major
> chunk of code that census shows as a major memory retenier (getMeta,
> plurals, pseudo, io.load) and try to optimize it and see the impact on
> raptor on FM and Settings.
> If I get a win on both, I submit a patch.
>

I'm looking forward to more data. I hope lazy qps will save us some
memory. Also, let's start talking about moving plurals into localization
files. Would that even be feasible for CLDR rules?

>
> Also, performance wise Settings with l10n.js and l20n.js are exactly on
> par. That's another great news. I still think there's room to improve
> l20n.js, but it seems that the baseline is there.
>

Are on par for non-default languages as well?

-stas