We want to start using Intl API in Firefox OS (bug 1170963), and I started migrating Gallery (bug 1170973). But it seems to me that Intl is lazy loaded, and when loaded for the first time, it uses a lot of memory. I tested Gallery with zero, one and two formatters and zero, one and two formatter format calls. The results: code: ``` var f = new Intl.DateTimeFormat('en-US', { month: 'long', year: 'numeric', }); var result = f.format(new Date()); ``` 1) no Intl.DateTimeFormat(), no .format() calls USS: 11.290 2) one Intl.DateTimeFormat(), no .format() calls USS: 11.330 3) one Intl.DateTimeFormat(), one .format() call USS: 12.270 4) one Intl.DateTimeFormat(), multiple format() calls, USS: 12.320 ========= We can pay a bit for Intl, since we will be able to remove l10n_date, and get better internationalization story, but I believe that this is way too high. In terms of performance, it seems that the first .format() costs us ~30-40ms on Flame. That's also quite high, but I believe it to be acceptable. I need help profiling the memory usage (I don't think I can reproduce it on desktop) and decide if we should hold on using Intl because of this bug.

Waldo, you were helping with bug 769872. Can you help me here or NI the right people who can help debug that?

Oh, to collect the data I'm using raptor.

Using Template app: Baseline: Metric Mean Median Min Max StdDev p95 -------------------------------- ------- ------- ------- ------- ------ ------- coldlaunch.navigationLoaded 193.800 195.500 176.000 210.000 12.335 210.000 coldlaunch.navigationInteractive 193.800 195.500 176.000 210.000 12.335 210.000 coldlaunch.visuallyLoaded 194.300 196.500 176.000 210.000 12.083 210.000 coldlaunch.contentInteractive 194.400 196.500 176.000 210.000 12.184 210.000 coldlaunch.fullyLoaded 194.800 197.500 176.000 210.000 11.990 210.000 coldlaunch.uss 8.330 8.400 8.200 8.400 0.090 8.400 coldlaunch.rss 26.120 26.150 26.000 26.200 0.087 26.200 coldlaunch.pss 12.470 12.500 12.400 12.500 0.046 12.500 Intl: Metric Mean Median Min Max StdDev p95 -------------------------------- ------- ------- ------- ------- ------ ------- coldlaunch.navigationLoaded 255.300 252.000 222.000 293.000 20.770 293.000 coldlaunch.navigationInteractive 256.000 255.500 222.000 293.000 20.857 293.000 coldlaunch.visuallyLoaded 256.400 255.500 224.000 294.000 20.607 294.000 coldlaunch.contentInteractive 256.600 255.500 224.000 294.000 20.621 294.000 coldlaunch.fullyLoaded 257.100 256.000 224.000 295.000 20.811 295.000 coldlaunch.uss 9.330 9.400 9.200 9.400 0.090 9.400 coldlaunch.rss 27.140 27.200 27.000 27.200 0.092 27.200 coldlaunch.pss 13.460 13.500 13.300 13.500 0.066 13.500 I guess some of the 60ms gets reduced when we use more JS, but the 1mb for Intl seems to be the same as in my previous tests and it is easier to notice in a minimized testcase.

Maybe just add some of this code that uses intl to dom/ipc/preload.js and see if we can share the extra memory among our forks?

100K on desktop versus 1MB on b2g suggests to me we're measuring different things. It's not implausible to me that desktop does something before your measurement to initialize Intl stuff, at onetime cost of ~900K. Then using Intl in a global adds that extra 100K as a separate step. Whereas on b2g, there is no "something" to incur the ~900K cost, so that Intl initialization is 100K+900K === ~1MB the first time. It wouldn't surprise me that if we moved Intl initialization into the prototype process pre-clone, we could get rid of the 30-40ms delay and incur the 900K cost only a single time. There'd still be the 100K hit for Intl on first use, and probably some smaller fraction of 30-40ms delay, to be sure. But it's not clear to me what action would incur that 900K cost, that wouldn't also incur the extra 100K cost. The self-hosting lazy-access stuff you found already was the extent of the lazy-initialize behavior I remember off the top of my head.

Just to be clear, why we want Intl: - properly formatted numbers in Firefox OS - properly formatted dates, times and datetimes in Firefox OS - significant reduction of work for localizers - all week day names, and month names are provided by Intl - no more datetime patterns formatting (we now ask localizers to prepare strings like that: "%M, %i, %H:%m") - remove l10n_date shim from all apps (that will save us some memory!) - l10n_date shim relies on mozL10n.get which is deprecated (bug 1020138) It's definitely the right direction for us, I just would like to make sure we don't pay too much and if we pay, it's per design, not because of some suboptimal code routine in Intl API :)

Actually, since we're using Intl in the system app, it seems that that's all it takes to get us on the warm path. In bug 1172699, we're going to initialize Intl with the system. After that, using more is fast: Without Intl in Gallery: Metric Mean Median Min Max StdDev p95 -------------------------------- -------- -------- ------- -------- ------ -------- coldlaunch.navigationLoaded 512.500 514.000 492.000 530.000 12.580 530.000 coldlaunch.navigationInteractive 514.200 516.000 493.000 533.000 13.068 533.000 coldlaunch.visuallyLoaded 788.900 788.000 749.000 828.000 26.201 828.000 coldlaunch.contentInteractive 789.600 788.000 750.000 829.000 26.101 829.000 coldlaunch.mediaEnumerated 789.900 789.000 750.000 829.000 26.201 829.000 coldlaunch.fullyLoaded 1022.400 1019.500 972.000 1103.000 42.945 1103.000 coldlaunch.pss 15.860 15.850 15.800 16.000 0.066 16.000 coldlaunch.rss 30.440 30.400 30.400 30.600 0.066 30.600 coldlaunch.uss 11.370 11.350 11.300 11.500 0.078 11.500 With Intl in Gallery: Metric Mean Median Min Max StdDev p95 -------------------------------- -------- -------- ------- -------- ------ -------- coldlaunch.navigationLoaded 536.900 534.500 485.000 575.000 33.140 575.000 coldlaunch.navigationInteractive 538.400 537.000 486.000 576.000 32.855 576.000 coldlaunch.visuallyLoaded 796.400 796.000 743.000 854.000 29.800 854.000 coldlaunch.contentInteractive 796.900 796.500 743.000 854.000 29.707 854.000 coldlaunch.mediaEnumerated 797.300 796.500 743.000 855.000 29.763 855.000 coldlaunch.fullyLoaded 1015.100 1021.000 948.000 1080.000 34.668 1080.000 coldlaunch.pss 15.840 15.850 15.700 15.900 0.066 15.900 coldlaunch.rss 30.430 30.400 30.300 30.500 0.064 30.500 coldlaunch.uss 11.340 11.350 11.200 11.400 0.066 11.400

We are now loading Intl during System load for time icon. It means that the cost of Intl pre-loading is there. (raptor confirms sub 1mb USS cost in system). That means that we should be able to now start using Intl in other places and it should not cost almost anything. Please, make sure to test memory/perf impact of the patches and if you see regressions caused by adding Intl calls, let me know. We can also move away from almost all uses of l10n_date.js toward Intl, which should give us perf/memory wins that will accumulate and hopefully give us a net win on the whole refactor.