1298122 - Optimize IO

Status: RESOLVED FIXED

(L20n :: General, defect)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

One of the identified bottlenecks of the l20n in XUL on larch branch is IO (see bug 1289530 comment 5 and later).

I'd like to try to make an attempt to get the IO as early as possible and as sync as necessary as it will unblock everything else in l20n startup path.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

harcoded IO -

changeset: https://hg.mozilla.org/try/rev/220a80e0acb9
try build: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2e0cb369c04f
talos: https://treeherder.mozilla.org/perf.html#/compare?originalProject=larch&originalRevision=7214320961ed&newProject=try&newRevision=2e0cb369c04f&framework=1&showOnlyImportant=0

Comment 2

[Staś Małolepszy :stas]

According to Zibi's findings which I also reproduced today it doesn't really matter when exactly the IO starts.  In (A) all of L20n's initialization is run after the documentReady() promise resolves.  In (B) the IO starts as soon as possible (as soon as we can query for <link rel="localization">).

  (A) IO starts: 100 ms, IO ends: 140 ms,
  (B) IO starts:  40 ms, IO ends: 140 ms.

In (B) we still need to guard the initial translation of the document with documentReady().  The reason for this is that we can't rely on the unguarded MutationObserver in XUL documents: bug 1294197.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

We increased the amount of talos runs in order to improve the reliability of the results.

New try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=370c9b0bb54b

we'll compare it against the results from bug 1289530 comment 14.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

This is long done.

https://wiki.mozilla.org/L20n/Firefox/Performance