If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Possible Tp4m-nochrome regression

RESOLVED FIXED

Status

()

Firefox for Android
General
P2
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: mbrubeck, Assigned: mbrubeck)

Tracking

({perf, regression})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
Tp appears to have regressed on birch sometime on 11/28 or 11/29.  Noise in the data makes it hard to pin down an exact changeset where the regression occurred:
http://graphs-new.mozilla.org/graph.html#tests=[[84,27,20]]&sel=none&displayrange=7&datatype=running

This might be caused by the viewport code from bug 694901 changing the browser size more often than necessary.
(Assignee)

Comment 1

6 years ago
Created attachment 577786 [details] [diff] [review]
instrumentation patch

This patch adds some timestamp logging to the viewport code; it doesn't identify any noticeably expensive operations during page load.

An alternate theory is that we recently fixed bugs that caused us to paint only part of the page; now that we are painting the whole page, rendering might be more expensive.
(Assignee)

Comment 2

6 years ago
After running some more Tp4m benchmarks on the surrounding changesets, it's clear this is a regression from bug 694901.
Matt, this is a P2 for you to make a call whether this can be fixed or we can live with the regression
Priority: -- → P2
tracking-fennec: --- → 11+
(Assignee)

Comment 4

6 years ago
This seems to have been caused by an increase in the number of redraws and size changes, which was fixed by work like bug 709492.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 709492
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
tracking-fennec: 11+ → ---
You need to log in before you can comment on or make changes to this bug.