Reconsider always running spare render process for android |
||
Issue descriptionI understand the idea is to hide the cost of start up, especially on android where starting a process takes quite awhile. I imagine this was originally added for desktop? Did it make a big improvement in page load times? Is there data on android as well? The trade off is always having spare renderer running all the time is pretty expensive, especially if device is under memory pressure (not necessarily from chrome). I don't know if we want to disable this altogether, or maybe there is a memory cut of above which this makes sense (probably higher than the current 1077M though I imagine) If we decide to keep this, then there are some other issues: * Spare should never force kill an existing process to free service slots. And the RenderProcessHostImpl::GetMaxRendererProcessCount check doesn't work because that's effectively infinite on android * Should hook up spare to memory pressure signal somehow, not keep it running forever. * Spare probably should avoid forcing android to kill any existing process as well, so maybe should be initially bound with waived binding only. That's a much more invasive change though.
,
Aug 8
Note that the spare might contribute to thrashing on low-end systems. This concern also applies to desktop platforms. This is tracked in issue 852905. I agree with the issues listed in #c0 (making the spare the first candidate for OS kills via waived binding + killing the spare by Chrome when under memory pressure).
,
Aug 14
I think the spare renderer was actually introduced first on Android a while ago by lizeb@, but I could be wrong, so adding lizeb@ on cc to confirm/deny. It does make sense to make it lowest priority, so it is killed first. Also, I wonder if we can use some other signal to create it in the first place, that is more indicative of potential navigation and use it only for the main frame.
,
Aug 22
Yes, this was indeed initially added for Android, more specifically Custom Tabs. In this case, it was created when Chrome was not foreground, and IIRC at least initially it had a "BIND_WAIVE_PRIORITY" binding. As for other signals, we have experimented with one a while ago: omnibox focused :) |
||
►
Sign in to add a comment |
||
Comment 1 by boliu@chromium.org
, Aug 8