Closed Bug 1371643 Opened 5 years ago Closed 5 years ago

Youtube Trending navigation start profile

Categories

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

55 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1365794
Performance ?

People

(Reporter: afilip, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [QRC][QRC_Analyzed])

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
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)
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
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)
See Also: → stylo-nightly, 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)
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)
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)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1330375
See Also: 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.
Performance: --- → ?
Whiteboard: [qf] [QRC][QRC_Analyzed] → [QRC][QRC_Analyzed]
You need to log in before you can comment on or make changes to this bug.