Open Bug 1388277 Opened 7 years ago Updated 2 years ago

Implement a process selector based on memory usage

Categories

(Core :: DOM: Content Processes, enhancement, P2)

enhancement

Tracking

()

Fission Milestone Future

People

(Reporter: gkrizsanits, Unassigned)

Details

(Whiteboard: [e10s-multi:+])

Currently we select process based on tab count, we should do something better. Either memory footprint or if it's possibly to measure memory fragmentation that can be another option.
Whiteboard: [e10s-multi:+]
dupe of bug 1066789 or bug 1066792 ?
(In reply to Mayank Bansal from comment #1)
> dupe of bug 1066789 or bug 1066792 ?

Not really.

Bug 1066789 is about moving away from an universal cap on the content process count.

Bug 1066792 is about an origin drive process selector.
Priority: -- → P2

I assume that our recent fission work touched many options here and things are quite well tweaked these days (or at least for good reasons we have not much options left here) ?

Flags: needinfo?(rjesup)

Actually, this is still relevant. Above 4 processes per eTLD+1 we start sharing processes, and choosing which one of the 4 to put it in could be smarter. Also, deciding when to share vs when to add another process could be better (than the current "new process if we have less than 4, else share"). If you have 40 massive google docs, 4 processes may be too few, and if you have 10 bugzilla tabs, you may be fine if they were all in 1 process.

This has been the source of major discussion in the fission group, and the current 4 processes-per-site was added late in the game since we didn't have anything smarter available to use.

Flags: needinfo?(rjesup)
Fission Milestone: --- → Future
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.