On 18/07/16 12:41, Staś Małolepszy wrote:
W dniu poniedziałek, 18 lipca 2016 12:29:30 UTC+2 użytkownik Staś Malolepszy
napisał:
Axel and Zibi suggested offline that we pick a Talos measure and stick
to it. I agree. This should be the feature we'll land first too. I
created a l20n-ts-paint branch [2] which is the minimal path that gets us
a single string localized with L20n (the URL bar placeholder).
[2] https://github.com/mozilla/gecko-dev/compare/master...stasm:l20n-ts-paint
I pushed to try from my l20n-ts-paint branch and the results are in.
Thanks
Here's the comparison between mozilla-central master branch (or default in hg
parlance) and l20n-ts-paint which is based on top of it:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b1c1f909fdd7&newProject=try&newRevision=b5a6bbfc8a2b&framework=1
There are minor regressions in session-restore (20-25ms, +2%) and a bigger one
(15ms, +5%) in tpaint. From the wiki [1]:
Tests the amount of time it takes the open a new window. This test
does not include startup time. Multiple test windows are opened in
succession, results reported are the average amount of time required
to create and display a window in the running instance of the browser.
(Measures ctrl-n performance.)
OTOH, ts_paint which opens and new window and waits for the testpage to load is
on par.
The measurements were done on a branch with an async version of L10nRegistry.
We need to better understand what are we paying for. A number of possible
culprits come to mind:
- we're running both the old and the new framework at the same time,
- we redo what the chrome registry does,
- we're async,
- we do more DOM modifications,
- we parse in JS,
- the resolver has complex logic and we might not be hitting the simple
string optimizations,
- other?
I'm also considering choosing tabbrowser.xml as our first target. It's
XUL/XBL, not too big [2] and has a few interesting quirks. For instance it
dispatches events when a tab's title changes which is non-trivial to do in the
async/mutation observer world. We talked to annevk about this and he suggested
emitting an event after a volley of mutations which has the list of changes
nodes in its details. I filed https://bugzil.la/1287403 for this.
What say you?
-stas
[1] https://wiki.mozilla.org/Buildbot/Talos/Tests#tpaint
[2]
https://dxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/tabbrowser.properties
I'm looking at
https://treeherder.mozilla.org/perf.html#/graphs?series=%5Bmozilla-inbound,e01d1e393493367fed5c0e0506c3e4207cda4107,1,1%5D&series=%5Bmozilla-inbound,80f9ee414d2bbedcb38937e90e9a961b95ea441b,1,1%5D&series=%5Bmozilla-inbound,29c253bef49b44be88ba4cf244e66d20ee02934c,1,1%5D&series=%5Bmozilla-inbound,c1b1c708a4991e8bfbcfed312c14b840ba1ac87a,1,1%5D,
and it seems that our values are within the common noise for these tests?
Alternative view, highlighting your test results against other try
pushes:
https://treeherder.mozilla.org/perf.html#/graphs?series=%5Btry,e01d1e393493367fed5c0e0506c3e4207cda4107,1,1%5D&series=%5Btry,80f9ee414d2bbedcb38937e90e9a961b95ea441b,1,1%5D&highlightedRevisions=b5a6bbfc8a2b
and
https://treeherder.mozilla.org/perf.html#/graphs?series=%5Btry,29c253bef49b44be88ba4cf244e66d20ee02934c,1,1%5D&series=%5Btry,c1b1c708a4991e8bfbcfed312c14b840ba1ac87a,1,1%5D&highlightedRevisions=b5a6bbfc8a2b.
For tpaint we're at the upper bound of the current data, but I'm not
sure that's a solid regression just yet. Session restore seems totally
within the regular noise for the test.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
