1533815 - A youtube live chat with rapid chats uses a lot of CPU. Makes nightly sluggish

Status: RESOLVED WORKSFORME

(Core :: Graphics: WebRender, enhancement, P3)

Description

[Mayank Bansal]

1. Using my local profile. WR enabled

2. Go to a live youtube chat : https://www.youtube.com/watch?v=LwXeoC6k0Lk
   This has a rapid chat window.

3. Watch the high CPU usage.

Profile: https://perfht.ml/2EIS1Sv

Comment 1

[Mayank Bansal]

Attachment: aboutsupport.txt

Comment 2

[Mayank Bansal]

OK. It is not the video playing that causes janks. I paused the video, and the chats still appear. Then I took a profile.

https://perfht.ml/2EKnHXr

Comment 3

[Mayank Bansal]

And another : https://perfht.ml/2EIS68K

It looks like we are continuously buidling display lists, but they dont cause janks. The janks come when we have selctor matching, followed by reflow.

ni? some people.

Comment 4

[Mayank Bansal]

oops, shouldnt ni so much.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

ni?ing is fine with me, fwiw :)

So, is the jank you're talking about the "347ms event processing delay"?

It looks like that's caused by some media queries changing, from nsPresContext::RefreshSystemMetrics, which is generally system dependent stuff (like default colors or such changing or what not).

That causes us to restyle the whole page, which is what takes long. Other than that, I don't see style so high in the profile, mostly some slow attribute selector matching (uBlock, maybe?).

If that 300ms+ pauses happen often, we should look into what causes it though, ThemeChanged is only supposed to affect rare stuff, like hight-contrast or other default system settings changing.

Comment 6

[Mayank Bansal]

So, is the jank you're talking about the "347ms event processing delay"?

My observstion on the jank was after I had looked at the profile. The actual subjective feeling when watching the live chat was of general sluggishness, and high CPU use (fan running)

It looks like that's caused by some media queries changing, from
nsPresContext::RefreshSystemMetrics, which is generally system dependent
stuff (like default colors or such changing or what not).

I do have set my Win10 machine to periodically change the system colors, which will also change the browsers tabbar color.

That causes us to restyle the whole page, which is what takes long. Other
than that, I don't see style so high in the profile, mostly some slow
attribute selector matching (uBlock, maybe?).

I do have ublcock installed.

Comment 7

[Kanchan Kumari QA]

Hello Mike, could you please look into the profile here? Thanks!

Comment 8

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

What I see in the profile is a lot of displaylist creation in the content process... we're (still) getting Polyfilled by Polymer, and periodically the JS causes a sync layout flush:

https://perfht.ml/2T3jPGb

Hey stpeter, do we know yet how close YouTube is to getting off of the v0 WebComponents spec, and getting us off of the Polymer polyfill on YouTube?

Comment 9

[Matt Woodrow (:mattwoodrow)]

Looks like at least some of the displaylist creation time is because RDL isn't working overly well. I've filed bug 1535507 for that.

Comment 10

[Peter Saint-Andre [:stpeter]]

Hey mconley, we reached out to our YT friends and the answer is "pretty darn close" but we don't have specific dates.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

Mayank, can you confirm this is worse with WebRender?

Comment 12

[Mayank Bansal]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #11)

Mayank, can you confirm this is worse with WebRender?

Its difficult to test with WR disabled, as I run into bug 1509656
But subjectively, WR-off and WR-on didnt feel any different.

Profile with WR off: http://bit.ly/2JQJToN

Comment 13

[Mayank Bansal]

https://www.youtube.com/watch?v=UVxU2HzPGug .
Start the video a bit, and then pause it. Let the chat mode be "Top chat". The chats eill continue to fly while the video is stopped.

WR off : http://bit.ly/2K0oOrM
WR on: http://bit.ly/2JPEj5Z

Comment 14

[Jeff Muizelaar [:jrmuizel]]

It looks like this is mostly a problem in the WebContent process with both display list building and webrender display list building taking a pretty big chunk of time.

Comment 15

[Miko Mynttinen]

Aside from calls to nsIFrame::RemoveDisplayItem(), this seems quite normal display list building profile. There is bug 1526970 filed for improving nsIFrame - display item management.

I think that the root problem here is that new chat messages invalidate the scrollbar, which disables RDL, and forces us to rebuild the whole display list.

Comment 16

[Glenn Watson [:gw]]

Is this still relevant (and if so, should it be in the WR component)?

Comment 17

[Mayank Bansal]

The original links dont work anymore. Might as well close this.