Status

()

For bugs in Firefox Desktop, the Mozilla Foundation's web browser. For Firefox user interface issues in menus, bookmarks, location bar, and preferences. Many Firefox bugs will either be filed here or in the Core product. Bugs for developer tools (F12) should be filed in the DevTools product. (more info)

For Firefox Screenshots system add-on bugs related to security and release tracking. Please file other bugs under https://github.com/mozilla-services/screenshots/issues. Non-security or release management bugs filed here will be closed as incomplete and moved to GitHub Issues

as a note, these seem to for the most part erase gains we saw while uplifting 56 to beta, put another way this is back to parity for many tests that we shipped firefox 55 with.
There are a few exceptions:
5% tp5o Main_RSS windows7-32 opt e10s 112,824,700.39 -> 118,028,869.02
7% tsvg_static summary osx-10-10 opt e10s 54.77 -> 58.46
3% tpaint summary windows7-32 opt e10s 201.05 -> 208.06
2% cart summary windows7-32 opt e10s 22.55 -> 23.01
tsvg_static has gone up/down, I suspect this might be an artifact of pgo:
https://treeherder.mozilla.org/perf.html#/graphs?timerange=7776000&series=mozilla-inbound,1455931,0,1&series=mozilla-beta,1533495,1,1&series=mozilla-inbound,1455996,1,1
as for tpaint, I am not sure, it is small and measures the time to create a new window.
the cart regression is small, and this is probably ok.
the tp5o main_rss regression, seems to be 100% related to this- at 5%, maybe that is the overhead for webext + screenshots?
Given that we rely heavily on PGO for linux/windows, there is some [un]lucky draws we take when changing code- I think we should focus on the smaller list, specifically on the tsvg_static (os) and tp5o Main_RSS on windows 7.

These are the same regressions we already decided to eat when we originally preffed this on in nightly.
The responsiveness and tsvg regressions are unfortunately most likely the result of enabling screenshots shortly after startup, rather than before first paint. I suppose we could try to shove some of that work into idle slices, but it may be easier said than done, since most of it is async, and we wouldn't want to do that for the before-first-paint loads.

(In reply to Kris Maglione [:kmag] from comment #5)
> These are the same regressions we already decided to eat when we originally
> preffed this on in nightly.
>
> The responsiveness and tsvg regressions are unfortunately most likely the
> result of enabling screenshots shortly after startup, rather than before
> first paint. I suppose we could try to shove some of that work into idle
> slices, but it may be easier said than done, since most of it is async, and
> we wouldn't want to do that for the before-first-paint loads.
Is that something that you think people would be comfortable uplifting to Beta at this point, or do you think it's too complex of a patch for that?
Is there anything we can do in the add-on at this point?
Any other ideas for improving this in the Beta timeline?

As Kris pointed out, there is a lot of overlap with the regressions we accepted in bug 1361792. Kris has a bunch of performance improvements landing in Nightly, but they aren't good candidates to uplift to address this in Beta. I confirmed with Jeff and Dave that we should accept the same regressions we did in Nightly and let this bug ride in Beta.