Closed Bug 1125872 Opened 9 years ago Closed 9 years ago

The default language is slow when GAIA_PRETRANSLATE=1

Categories

(Firefox OS Graveyard :: Gaia::L10n, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: stas, Unassigned)

Details

Attachments

(1 file)

46 bytes, text/x-github-pull-request
zbraniecki
: review+
Details | Review
I've run a few perf-tests today (Gecko 38, today's master) and noticed something peculiar:  the default locale is a good deal slower than non-default ones when GAIA_PRETRANSLATE is 1 (the default value). 

settings (means in ms)     PRE=1  PRE=0  Δ     Sig?
-------------------------  -----  -----  ----  ----
moz-chrome-dom-loaded       1099    913  -186  *   
moz-chrome-interactive      1100    914  -186  *   
moz-app-visually-complete   2074   2022   -52  *   
moz-content-interactive      799    822    23  *   
moz-app-loaded              4928   4847   -81  *  


I suspect that the culprit is the setTimeout here:

https://github.com/mozilla-b2g/gaia/blob/d34aff2c9066785d2cfb37a05a6c1106a5b514a0/shared/js/l10n.js#L1631

Without the setTimeout, the results compared to master are similar:

settings (means in ms)       sT  no-sT  Δ     Sig?
-------------------------  ----  -----  ----  ----
moz-chrome-dom-loaded      1099    931  -168  *   
moz-chrome-interactive     1100    931  -168  *   
moz-app-visually-complete  2074   2026   -47  *   
moz-content-interactive     799    840    41  *   
moz-app-loaded             4928   4819  -110  * 

It's still a bit slower than with GAIA_PRETRANSLATE=0, possibly due to the initObserver() function being run in the second scenario.

I have a number of ideas of how to clean up this code and make it faster.  I'll experiment tomorrow.
Zibi, do you remember why we don't call initObserver() in init if pretranslate is true?  I'm not sure if I understand that part.
Flags: needinfo?(gandalf)
Yup: bug 1108096 comment 22, point 3.

Glad you debugged it!

(In reply to Staś Małolepszy :stas from comment #1)
> Zibi, do you remember why we don't call initObserver() in init if
> pretranslate is true?  I'm not sure if I understand that part.

The logic was that since we need to pretranslate the whole document, nodes injected between init() and onReady() will be translated anyway, so we don't need to observe them and collect them into pendingElements.

I must admit that I assumed that in pretranslated case we're waiting for 'complete' before initializing, but I guess we changed it at some point.
Flags: needinfo?(gandalf)
Attached file A naive pull request
Easy win?
Attachment #8554608 - Flags: review?(gandalf)
Comment on attachment 8554608 [details] [review]
A naive pull request

It looks promising to me, but can you test it against another app? Settings is the only of the default apps that doesn't use defer to load l10n.js

I tested against Settings and also got a nice perf win, but then testing against SMS I didn't get any diff.
Attachment #8554608 - Flags: review?(gandalf) → review+
I measured a few other apps on 2.2, Gecko 37 (2.2 seems more stable than master at present).


calendar (means in ms)     Base  Patch  Δ   Sig?
-------------------------  ----  -----  --  ----
moz-chrome-dom-loaded      1135   1173  38  *   
moz-chrome-interactive     1151   1188  37  *   
moz-app-visually-complete  1630   1650  19      
moz-content-interactive    1631   1650  19      
moz-app-loaded             1632   1651  19      

camera (means in ms)       Base  Patch  Δ    Sig?
-------------------------  ----  -----  ---  ----
moz-chrome-dom-loaded       802    795   -8      
moz-chrome-interactive      803    796   -7      
moz-app-visually-complete  1131   1110  -21      
moz-content-interactive    1871   1861  -10      
moz-app-loaded             1872   1861  -10      

clock (means in ms)        Base  Patch  Δ  Sig?
-------------------------  ----  -----  -  ----
moz-chrome-dom-loaded       772    775  3      
moz-chrome-interactive      875    881  6      
moz-app-visually-complete  1070   1074  4      
moz-content-interactive    1071   1075  4      
moz-app-loaded             1072   1076  4      

communications/dialer (means in ms)  Base  Patch  Δ   Sig?
-----------------------------------  ----  -----  --  ----
moz-chrome-dom-loaded                 517    522   4      
moz-chrome-interactive                561    565   4      
moz-app-visually-complete             518    522   4      
moz-content-interactive               536    542   6      
moz-app-loaded                       1383   1380  -4      

communications/contacts (means in ms)  Base  Patch  Δ    Sig?
-------------------------------------  ----  -----  ---  ----
moz-chrome-dom-loaded                   721    715   -6      
moz-chrome-interactive                  767    755  -12      
moz-app-visually-complete               981    947  -34  *   
moz-content-interactive                1044   1030  -14      
moz-app-loaded                         1047   1033  -14      

settings (means in ms)     Base  Patch  Δ     Sig?
-------------------------  ----  -----  ----  ----
moz-chrome-dom-loaded      1117    941  -176  *   
moz-chrome-interactive     1117    941  -176  *   
moz-app-visually-complete  2129   1988  -141  *   
moz-content-interactive     817    852    35  *   
moz-app-loaded             4925   4818  -107  *   

sms (means in ms)          Base  Patch  Δ    Sig?
-------------------------  ----  -----  ---  ----
moz-chrome-dom-loaded       909    903   -6      
moz-chrome-interactive      939    932   -7      
moz-app-visually-complete   985    974  -12      
moz-content-interactive    1332   1314  -18      
moz-app-loaded             1043   1032  -12      


Looks like we're mostly speeding up in Settings and a little bit in Contacts.  Other measured apps are unaffected, except for a tiny slow down in Calendar for the first two perf events.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: