[meta] Meta: Prestart enough content processes to avoid delays when loading typical pages in Fission
Categories
(Core :: DOM: Navigation, enhancement, P3)
Tracking
()
People
(Reporter: jesup, Assigned: jesup)
References
(Blocks 1 open bug)
Details
(Keywords: meta, perf, Whiteboard: fission-perf, fission-soft-blocker)
Many pages have 1 or more iframes which in Fission are likely to need new content processes to load. We need to attempt to have enough prestarted processes that we don't delay startup waiting for processes to load and initialize.
The number to prestart probably should be adaptive to a number of things:
- The process creation delay for the machine/OS
** Different OSes vary in the overhead to create a process
** Processor speed and disk type also affect process start time
** Memory pressure may affect it - History of the number of processes needed
- (maybe) Prediction based on the top-level domain being loaded
- (maybe) The origins already existing in processes (common iframe origins)
We could use an algorithm that dynamically adapts to whether it finds it needs to create more on-the-fly too often, which will help a lot with the scaling to the machine and the load on the machine, perhaps with some presets or measurements during browser startup to seed the adaption (since we create several processes during startup, we can measure the time it takes).
We can aggressively create processes during parse similar to how we speculatively connect; this might help especially on machines with spare cores. Low-core machines might see no improvement if process creation takes away from parsing of the main page, and even might (maybe) hurt visual metrics if it delays mainpage rendering to speed an iframe creation time.
Assignee | ||
Comment 1•5 years ago
|
||
<wrong bug>
Updated•5 years ago
|
Comment 2•5 years ago
|
||
:jesup, I believe you're actively working on this right now. Can this bug be duped against your prelaunch bug?
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Tracking for Fission M7 Beta because this perf meta bug doesn't need to block Fission Nightly.
Assignee | ||
Updated•4 years ago
|
Comment 4•4 years ago
|
||
We no longer block the main page so we should look into lowering the preallocated process to maybe 1, and then attempt to allocate 2 more while DocumentChannel waits for Necko channel to return.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
This is not required for Beta and we can revisit this later before MVP to see if there's work identified to do here.
Comment 6•4 years ago
|
||
Removing from QF since it's a meta bug.
Comment 8•3 years ago
|
||
This bug is a soft blocker for Fission MVP. We'd like to fix it before our Release channel rollout, but we won't delay the rollout waiting for it.
Assignee | ||
Updated•3 years ago
|
Description
•