Open Bug 1667157 Opened 8 months ago Updated 2 months ago

FirstPaint performance regression with Fission in browsertime

Categories

(Core :: DOM: Content Processes, defect, P2)

defect

Tracking

()

ASSIGNED
Fission Milestone M8

People

(Reporter: jesup, Assigned: jesup)

Details

(Whiteboard: fission-perf)

We see a regression in firstvisualchange/FNBP/etc metrics with browsertime with fission turned on on 2017 Acer windows laptop (reference laptop). This is likely related to the process-switch to a new process that happens during the load.

See browsertime results here: https://docs.google.com/spreadsheets/d/1UBRh4vbS9vXBm-0h7xc3lOWYJOW8VSGLirCXnQ977FQ/edit#gid=756910926

<deleted>

Summary: FirstPaint performance regression with Fission in browsertime on low-end HW → FirstPaint performance regression with Fission in browsertime

M7

Severity: -- → S3
Fission Milestone: --- → M7
Priority: -- → P2
Whiteboard: [fission] → fission-perf

From jesup

It'd be helpful to look at profiles of fission vs e10s loads, and see if there's any useful things we can do to minimize the process-switch overhead (moving initializations of things, lazifying things, etc). More generally, we see small perf regressions avg. 3-6%) on load in tp6 raptor, and I see very close to a wash on visual metrics on high-end HW. And FVC and FP on the larger high-end test weren't much regressed, note. On the 2-core it was significant (25-35%)

Randell will re-do these measurements for both high-end and low-end to get the latest numbers, as the old ones are 5 months old.

Flags: needinfo?(rjesup)
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
Flags: needinfo?(rjesup)

Only visual metrics should be blocking M7.

Fission Milestone: M7 → M8
You need to log in before you can comment on or make changes to this bug.