1482600 - Opening a single tab in the background uses lots of CPU, janking the foreground tab

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[Mayank Bansal]

Attachment: aboutsupport.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180810220115

Steps to reproduce:

1. Use a fresh nightly profile
2. Optional : Install adblockplus to reduce noise from loading ads and tracking scripts
3.  go to https://www.androidpolice.com/page/2/
4. ctrl+click on any of the article links , such that the article opens in the background tab


Actual results:

high CPU usage. 80-90% of my 2C/4T processor. 
this makes scrolling on the foreground suffer. 
Typical usage scenario is to open such a pge with many aticles, and then open a few of those in background, while you continue scrolling on the main page.

Profile: https://perfht.ml/2vXAvFv
This is with opening a tab in background, and not scrolling the foreground.


Expected results:

less so.
If this is "by design" because of increased use of parallel threads/processes, I would be satisfied with a WONTFIX.

Comment 1

[Mayank Bansal]

ni? mconley, as he has been looking at this kind of stuff

Comment 2

[Mayank Bansal]

For sites with less content, no tracking overall, use bmo.



1. open https://bugzilla.mozilla.org/show_bug.cgi?id=1467044#c33  in the forefround
2. Ctrl+click the link in the comment of step 1.
3. Watch CPU use spike.

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

Comment 3

[Mayank Bansal]

HEre is a profile with non-WR : https://perfht.ml/2B42o4E 
STR are same as cpmment 2

Comment 4

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

It's a bit difficult for me to tell what's happening here because the profiles aren't symbolicated for some reason... are you using a Mozilla-provided build of Firefox?

One thing I _can_ detect is that the parent process is janking a bit when it's launching a subprocess, since that still occurs on the main thread.

Mayank, if you open X background tabs (where X is the number of content processes you're set up to use at dom.ipc.processCount - the default is 4), and _then_ attempt the STR, are things smoother?

If that's the case, I think we can chalk this up to the sync launching of subprocesses, and dupe this over to bug 1446161, where we're trying to make process launching fully async.

Comment 5

[Mayank Bansal]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)
> It's a bit difficult for me to tell what's happening here because the
> profiles aren't symbolicated for some reason... are you using a
> Mozilla-provided build of Firefox?

Yes these are official nightlies. Will file a bug and cc you, as i dont have enough knowledge here


> 
> One thing I _can_ detect is that the parent process is janking a bit when
> it's launching a subprocess, since that still occurs on the main thread.
> 
> Mayank, if you open X background tabs (where X is the number of content
> processes you're set up to use at dom.ipc.processCount - the default is 4),
> and _then_ attempt the STR, are things smoother?
> 
> If that's the case, I think we can chalk this up to the sync launching of
> subprocesses, and dupe this over to bug 1446161, where we're trying to make
> process launching fully async.

Will try and update here

Comment 6

[Mayank Bansal]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)
> It's a bit difficult for me to tell what's happening here because the
> profiles aren't symbolicated for some reason... are you using a
> Mozilla-provided build of Firefox?

This appears to be solved by bug 1481619/bug 1482690 , i think

> 
> One thing I _can_ detect is that the parent process is janking a bit when
> it's launching a subprocess, since that still occurs on the main thread.
> 
> Mayank, if you open X background tabs (where X is the number of content
> processes you're set up to use at dom.ipc.processCount - the default is 4),
> and _then_ attempt the STR, are things smoother?
> 
> If that's the case, I think we can chalk this up to the sync launching of
> subprocesses, and dupe this over to bug 1446161, where we're trying to make
> process launching fully async.

Things arent much smoother. Here is a symbolicated profile with bugzilla pages opened in backround and foreground, WR enabled: https://perfht.ml/2w7pBgJ

Enabling WR makes this worse.

Comment 7

[Mayank Bansal]

Here is a profile which makes sure that the new tab opened will be a new process (WR enabled):

https://perfht.ml/2KRR4bA

From the looks of it, background tab janks due to  lots of time spent in thread creation of NSS, audio, sandbox, BHR, 
Foreground tab janks due to time spent in Brotli WOFF decompressing, opentype CFF font parsing, stylo, hashing, stylo, and reflow

Comment 8

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

I think I see what you're talking about in these profiles. There are some big zones where it looks like the threads you're sampling aren't getting serviced. No obvious culprits really stand out to me... you filed bug 1483462 about Kaspersky... if you disable Kaspersky, does the CPU usage settle a bit?

Comment 9

[Mayank Bansal]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #8)
> I think I see what you're talking about in these profiles. There are some
> big zones where it looks like the threads you're sampling aren't getting
> serviced. No obvious culprits really stand out to me... you filed bug
> 1483462 about Kaspersky... if you disable Kaspersky, does the CPU usage
> settle a bit?

https://perfht.ml/2OZjtPh  : no kaspersky, no WR

Disabling Kaspersky and WR doesnt really help much. 
The CPU use is not high consistently. It gets almost 100% for maybe about a second while the tab opens in the background, and does styling, js etc

Comment 10

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

(In reply to Mayank Bansal from comment #9)
> Disabling Kaspersky and WR doesnt really help much. 
> The CPU use is not high consistently. It gets almost 100% for maybe about a
> second while the tab opens in the background, and does styling, js etc

Alright, in that case, I think we're working as designed here. We're using a bunch of threads to retrieve, construct, style, execute and paint the page. I don't think there's anything problematic that's also actionable here. Please re-open if I've missed something.

Comment 11

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

Actually, I think I'll hang this off of a separate bug - we're starting to investigate lowering the process priority of background tabs. Perhaps that'll help this.

Comment 12

[Paul Oiegas [:poiegas], PM for Ecosystem QA (OMC, New Tab, Contextual, Nimbus, Experiments), Services QA (VPN, FxA/Subplat, Relay, Monitor), WebCompat QA, and Solo QA teams), TestRail admin, etc]

Hey Mike, can we move this issue to DOM: Content Processes component since you've added Bug 1476981 as a dependency? Keeps showing up on our triage lists as untriaged.

Comment 13

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

Sure.

Comment 14

[Mayank Bansal]

This has gotten nowhere, and I dont think i can reproduce this. Closing this.