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
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
Ting-Yu, could you help to follow Chris's investigation in comment 2? Thanks.
Assignee: nobody → 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
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.
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.
Maybe Andrei can re-profile with the Stylo pref (look for 'servo' in about:config) flipped in a recent nightly?
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
Hey Filip, Can you please use an Interval of 2ms instead? Sub-millisecond intervalling doesn't work very well (or at all) on Windows.
Hi Mike, Changed the interval to 2ms as you asked and here is the profile: https://perfht.ml/2uvxBt3
Hey Bas, So I took a look at https://perfht.ml/2uvxBt3 and recorded my exploration, and have some notes, 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? : https://air.mozilla.org/the-joy-of-profiling-episode-7/ : https://docs.google.com/document/d/1yp7nNXZPLCkPKKYU2I_0G--iiiqUOyaHicqTwSHyi3o/edit#heading=h.m6i69gcr98
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
(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).
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1330375
(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.