Closed Bug 1235910 Opened 5 years ago Closed 5 years ago

Investigate discrepancy between e10s & non-e10s responsiveness in Beta 44

Categories

(Firefox :: General, defect, P1)

43 Branch
defect

Tracking

()

RESOLVED INVALID
Tracking Status
e10s + ---

People

(Reporter: vladan, Unassigned)

References

(Blocks 1 open bug, )

Details

The BHR hang rate for e10s is twice that of non-e10s, even for profiles without addons, and despite the BHR fix in bug 1234618, and despite the lack of child-process BHR reporting (bug 1228437):

https://github.com/poiru/e10s_analyses/blob/beta/beta/e10s_experiment_without_extensions.ipynb

Median difference in hangs over 100ms per minute is 19.84 (e10s 38.63 hangs/minute, non-e10s 18.79 hangs/minute)
Flags: needinfo?(jmathies)
We're going to need to continue validating the BHR measurement and I've also asked Birunthan to re-run these analyses with more data.

OThers can help us verify that BHR corresponds to reality by installing this toolbar extension: https://github.com/chutten/statuser/blob/gh-pages/dist/statuser-0.0.3.xpi It increments a counter whenever BHR records an event lasting more than 100ms on the main thread.
It looks like the problem here is that bug 1234618 didn't land on beta when we thought it did. Thus, the BHR measurements there are not valid.

I wasn't able to tell which buildids are included in the Aurora analyses in comment 1, but I suspect they include builds lacking bug 1234618. So that data is also invalid.

I ran a simple analysis on Aurora including only buildids with the patch in bug 1234618. It's not as statistically valid because I just broke people up based on whether they have e10s enabled or not (i.e., they're allowed to choose whether to enable e10s, rather than Mozilla choosing for them). I also excluded people with add-ons.

http://people.mozilla.org/~wmccloskey/aurora-analysis.html

e10s: 1.43 hangs >100ms per minute
non-e10s: 11.35 hangs >100ms per minute
Flags: needinfo?(jmathies)
tracking-e10s: --- → ?
Ritu, which beta did this get into?
Flags: needinfo?(rkothari)
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #4)
> Ritu, which beta did this get into?

Hi Brad, if you are asking about the patch from bug 1234618 (cset https://hg.mozilla.org/releases/mozilla-beta/rev/2e553b97f22f), it landed in m-b on 12/29/15 and so should have been in 44.0b4.
Flags: needinfo?(rkothari)
Vladan, what are the next steps here?
Blocks: e10s-perf
Flags: needinfo?(vladan.bugzilla)
Priority: -- → P1
(In reply to Ritu Kothari (:ritu) from comment #5)
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #4)
> > Ritu, which beta did this get into?
> 
> Hi Brad, if you are asking about the patch from bug 1234618 (cset
> https://hg.mozilla.org/releases/mozilla-beta/rev/2e553b97f22f), it landed in
> m-b on 12/29/15 and so should have been in 44.0b4.

Ritu: your link says this landed on m-b on December 31st, no? If that's the case, wouldn't it have only made it into beta5 or beta6 instead?
Flags: needinfo?(vladan.bugzilla) → needinfo?(rkothari)
(In reply to Vladan Djeric (:vladan) -- please needinfo from comment #7)
> (In reply to Ritu Kothari (:ritu) from comment #5)
> > (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #4)
> > > Ritu, which beta did this get into?
> > 
> > Hi Brad, if you are asking about the patch from bug 1234618 (cset
> > https://hg.mozilla.org/releases/mozilla-beta/rev/2e553b97f22f), it landed in
> > m-b on 12/29/15 and so should have been in 44.0b4.
> 
> Ritu: your link says this landed on m-b on December 31st, no? If that's the
> case, wouldn't it have only made it into beta5 or beta6 instead?

Hi Vladan, since this was pushed on 12/31 and we skipped b5 in 44 cycle, this should have been in 44.0b6.
Flags: needinfo?(rkothari)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.