Closed Bug 1667696 Opened 1 year ago Closed 11 months ago

CONTENT_FULL_PAINT_TIME/CONTENT_FRAME_TIME regression on 2020-07-28

Categories

(Core :: Graphics: WebRender, defect)

Desktop
Windows
defect

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- fixed

People

(Reporter: mattwoodrow, Assigned: nical)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Looking at the dashboard it appears there was a regression on 2020-07-28 - https://metrics.mozilla.com/public/sguha/ds-283/dashboard.html

CONTENT_FULL_PAINT_TIME goes from 6.84 -> 8.01
CONTENT_FRAME_TIME foes from 0.10 -> 0.11

The regression range from the first nightly build on the 27th to the last on the 28th is this: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=798bdad605b985a71cd204a56bb816dea503d432&tochange=7b8c4f32cdde947c1b1f942905fbc5039b6d1c65

Given that this regresses CONTENT_FULL_PAINT_TIME and not CONTENT_PAINT_TIME or COMPOSITE_TIME, it seems likely that the regression is in display list deserialization/scene building.

Nothing in that range seems particularly likely, except maybe Bug 1648405, or Bug 1623792.

Nical, do you think it's possible that the switch to crossbeam could cause slowness here?

Flags: needinfo?(nical.bugzilla)

I would be surprised that the switch to crossbeam channel caused a regression on windows, it even improved out tscrollx score by 4~5% on linux and other projects have reported seeing improvements moving from std channels to crossbeam.

It should be easy enough to switch back to std channels on windows and see if it fixes the slowness.

Flags: needinfo?(nical.bugzilla)
Blocks: gfx-triage
Flags: needinfo?(gwatson)

We decided to (temporarily?) revert the patch that adds the IS_IDENTITY flag as it's an easy patch to revert and see if it has any effect on that telemetry number.

Depends on: 1668696
Flags: needinfo?(gwatson)

While we measuered somewhat surprisingly high performance improvements on linux when replacing standard channels with crossbeam ones on Linux, there has been a CONTENT_FRAME_TIME regression on Windows around the same time. In doubt, this patch makes us use standard channels on Windows to see if it fixes the regression. This patch will be reverted if it doesn't turn out restore the CONTENT_FRAME_TIME numbers.

Swgl needs to continue using crossbeam because it depends on select which doesn't exist in standard channels.

Assignee: nobody → nical.bugzilla
Status: NEW → ASSIGNED
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e6d7b596358d
Use standard rust channels on Windows. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Let's keep it open at least until we have validated that not using crossbeam channels in Windows fixed the issue.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 1 year ago11 months ago
Resolution: --- → FIXED
Keywords: regression
OS: Unspecified → Windows
Regressed by: 1648405
Hardware: Unspecified → Desktop
No longer blocks: gfx-triage
You need to log in before you can comment on or make changes to this bug.