Youtube Trending navigation start profile

RESOLVED DUPLICATE of bug 1365794

Status

()

RESOLVED DUPLICATE of bug 1365794
a year ago
a year ago

People

(Reporter: afilip, Unassigned)

Tracking

(Blocks: 2 bugs)

55 Branch
x86_64
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf] [QRC][QRC_Analyzed] , URL)

(Reporter)

Description

a year ago
teps to reproduce:
1. Launch browser..
2. Fill Youtube.com in Navigation Start, then press enter. 
2. Record with Gecko Profile:
3. Access Youtube Trending
4. Share the profile


Gecko profile:
https://perfht.ml/2r2dMV0

Comment 1

a year ago
Chris, could you help to have first profiling in this bug?
Assignee: nobody → cpearce
Flags: needinfo?(cpearce)
It's not clear from the STR what the unexpected behaviour here is. Please make it clear when filing bugs what the unexpected and expected behaviour is.

Having said that, I see a large amount of JS running, and deep in a JS call context script calls mozilla::dom::ElementBinding::get_clientWidth and that causes a layout flush, and then we block the main thread in content process 2 for 400ms. There's also a huge 400ms GC pause near the end of the run.

I'm going to triage this into layout on the assumption that the flush is causing the issue here.
Assignee: cpearce → nobody
Component: General → Layout: Block and Inline
Flags: needinfo?(cpearce)

Comment 3

a year ago
Ting-Yu, could you help to follow Chris's investigation in comment 2? Thanks.
Assignee: nobody → tlin
Flags: needinfo?(tlin)
I redo a profile from my Mac. Beside the large amount of JS running, I saw a 748ms of event process delay blocking the main process. Most of them are function calls from the gecko style system like nsCSSRuleProcessor::RulesMatching, SelectorMatches. I don't see something fishy from the layout system, so I'm hoping stylo can help make this scenario faster.

http://bit.ly/2tyjza4
Flags: needinfo?(tlin)
Assignee: tlin → nobody

Comment 5

a year ago
Jet, I have no good clue to continue this. Could you help to triage this bug based on Chris's and Tingyu's investigation? Thanks.
Flags: needinfo?(bugs)
My quick look at the profile indicates that bug 1330412 and bug 1352499 should help this (at least the Style/Layout portion of the profile.) The JS/GC portion may need its own bug(s) or duped to others.
Flags: needinfo?(bugs)

Updated

a year ago
See Also: → bug 1330412, bug 1352499
Whiteboard: [QRC][QRC_NeedAnalysis] → [qf] [QRC][QRC_Analyzed]
Maybe Andrei can re-profile with the Stylo pref (look for 'servo' in about:config) flipped in a recent nightly?
Flags: needinfo?(afilip)
(Reporter)

Comment 8

a year ago
Here is the Profile with the Stylo enabled.

https://perf-html.io/public/69c3a993ef15f68fcb8d1ca06bf889b9354a3b58/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-6-1-5

If there is anything else that I should change like Interval or buffer size i will gladly take another profile.For this profile I used an Interval of 0.3 ms and a buffer size of 540mb
Flags: needinfo?(afilip)
Hey Filip,

Can you please use an Interval of 2ms instead? Sub-millisecond intervalling doesn't work very well (or at all) on Windows.
Flags: needinfo?(afilip)
(Reporter)

Comment 10

a year ago
Hi Mike,


Changed the interval to 2ms as you asked and here is the profile: 

https://perfht.ml/2uvxBt3
Flags: needinfo?(afilip)
Hey Bas,

So I took a look at https://perfht.ml/2uvxBt3 and recorded my exploration[1], and have some notes[2], but here are some findings that the Graphics team might find interesting (despite how many samples are missing):

Long paint: https://perfht.ml/2eIBAfG
Long paint 2: https://perfht.ml/2eILzkS
Long paint 3: https://perfht.ml/2eIL3n3

Also a general question - from the stacks in here, it looks like we're using BasicLayers... but I see stack frames in the compositor thread mentioning LayerManagerMLGPU, and that's apparently part of something called AdvancedLayers (at least according to https://searchfox.org/mozilla-central/source/gfx/doc/AdvancedLayers.md). Do these both somehow refer to different things, or is some part of our graphics infrastructure confused, or am I misinterpreting?

[1]: https://air.mozilla.org/the-joy-of-profiling-episode-7/
[2]: https://docs.google.com/document/d/1yp7nNXZPLCkPKKYU2I_0G--iiiqUOyaHicqTwSHyi3o/edit#heading=h.m6i69gcr98
Flags: needinfo?(bas)
And this question is for dholbert - I noticed some long interruptible reflows in here... like, really long. All over 120ms. Shouldn't we be interrupting and painting long before reaching that amount of time?

For reference: https://perf-html.io/public/a49c5ff8936c6114c5b387c546ad80ff35a08ed2/calltree/?callTreeFilters=prefix-0123456789abcde9abghAU6CxdyiyjykxM1xM2xM3xM4xZ0xM6xM7xM8xM9L6yBqI8&hiddenThreads=1-4-3&range=10.1092_18.0288~16.7526_17.6202&thread=6&threadOrder=0-2-3-4-1-6-5
Flags: needinfo?(dholbert)
(In reply to Mike Conley (:mconley) - Buried in needinfo / review backlog, eating my way out from comment #13)
> And this question is for dholbert - I noticed some long interruptible
> reflows in here... like, really long. All over 120ms. Shouldn't we be
> interrupting and painting long before reaching that amount of time?

As I recall, "interruptible reflows" only get interrupted by user input -- see the "HavePendingInputEvent()" condition here:
https://dxr.mozilla.org/mozilla-central/rev/7d2e89fb92331d7e4296391213c1e63db628e046/layout/base/nsPresContext.cpp#2969-2974

So, in that profile, there was probably no user input during those reflows -- so we err on the side of running the reflow to completion (since it's possible/likely we'll end up repeating some redundant work if we interrupt reflow & schedule another one).
Flags: needinfo?(dholbert)

Updated

a year ago
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1330375

Updated

a year ago
See Also: bug 1352499
Duplicate of bug: 1365794
Flags: needinfo?(bas)
(In reply to Mike Conley (:mconley) - Buried in needinfo / review backlog, eating my way out from comment #12)
> Also a general question - from the stacks in here, it looks like we're using
> BasicLayers... but I see stack frames in the compositor thread mentioning
> LayerManagerMLGPU, and that's apparently part of something called
> AdvancedLayers (at least according to
> https://searchfox.org/mozilla-central/source/gfx/doc/AdvancedLayers.md). Do
> these both somehow refer to different things, or is some part of our
> graphics infrastructure confused, or am I misinterpreting?
> 

Bas explained this to me over Vidyo. Essentially, AdvancedLayers is not some advanced version of BasicLayers, despite the name. They're two different things, and can be running simultaneously.
You need to log in before you can comment on or make changes to this bug.