Implement a process selector based on memory usage
Categories
(Core :: DOM: Content Processes, enhancement, P2)
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.
Reporter | ||
Updated•7 years ago
|
Comment 1•7 years ago
|
||
dupe of bug 1066789 or bug 1066792 ?
Reporter | ||
Comment 2•7 years ago
|
||
(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.
Reporter | ||
Updated•7 years ago
|
Comment 3•2 years ago
|
||
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) ?
Comment 4•2 years ago
|
||
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.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•