Use separate content processes for e10s browsing and thumbnail generation

RESOLVED WONTFIX

Status

()

P3
normal
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: mconley, Assigned: blassey)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox42 affected)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
With e10s enabled and dom.ipc.processCount = 1, the content process is shared between general browsing and the thumbnail generation process.

The thumbnail generation process is going to periodically load pages in the background, render them, and generate thumbnails from them. It might be a nice perf win to take that work out of the content process that the user is browsing with.

We'd probably want to distinguish between this process and general content processes somehow with Telemetry, etc.
(Assignee)

Updated

3 years ago
tracking-e10s: ? → +
Created attachment 8640468 [details] [diff] [review]
force_own_process.patch

Here's a patch to do this. It's probably reasonable to have a discussion as to whether we want to do this or not.
Assignee: nobody → blassey.bugs
Attachment #8640468 - Flags: review?(wmccloskey)
Comment on attachment 8640468 [details] [diff] [review]
force_own_process.patch

Review of attachment 8640468 [details] [diff] [review]:
-----------------------------------------------------------------

I don't think we should do this for thumbnailing. If I have two content processes running, I don't want to waste one of them for just thumbnails. I think I'd get much more benefit if my tabs were split between them, with thumbnailing in one of them.

However, I think it might make sense to do a more general version of this. I'd really like to see two attributes on the frame element, both strings:
- processTribe
- processFamily

Two frames that are in different processTribes can never run in the same process. Two frames that are in the same processFamily must always live in the same process. (Please suggest better names.)
Attachment #8640468 - Flags: review?(wmccloskey) → review-
(Assignee)

Updated

3 years ago
Priority: -- → P3

Updated

3 years ago
Blocks: 1249880

Comment 3

3 years ago
I agree with Bill that we shouldn't do this particular thing. Process tribes are something to design later, not worth leaving a bug open.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.