1371643 - Youtube Trending navigation start profile

Status: RESOLVED DUPLICATE of bug 1365794

(Core :: Layout: Block and Inline, defect)

Description

[Filip Andrei]

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

[Bobby Chien]

Chris, could you help to have first profiling in this bug?

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

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.

Comment 3

[Bobby Chien]

Ting-Yu, could you help to follow Chris's investigation in comment 2? Thanks.

Comment 4

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

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

Comment 5

[Bobby Chien]

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.

Comment 6

[Jet Villegas (inactive)]

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.

Comment 7

[Andrew Overholt [:overholt]]

Maybe Andrei can re-profile with the Stylo pref (look for 'servo' in about:config) flipped in a recent nightly?

Comment 8

[Filip Andrei]

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

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Hey Filip,

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

Comment 10

[Filip Andrei]

Hi Mike,


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

https://perfht.ml/2uvxBt3

Comment 11

[Mike Conley (:mconley) (:⚙️)]

I analyzed this last Friday on The Joy of Profiling Episode 7:

https://air.mozilla.org/the-joy-of-profiling-episode-7/

Notes: https://docs.google.com/document/d/1yp7nNXZPLCkPKKYU2I_0G--iiiqUOyaHicqTwSHyi3o/edit#heading=h.m6i69gcr98

Comment 12

[Mike Conley (:mconley) (:⚙️)]

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

Comment 13

[Mike Conley (:mconley) (:⚙️)]

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

Comment 14

[Daniel Holbert [: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).

Comment 17

[Mike Conley (:mconley) (:⚙️)]

(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.