User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20151221151411 Steps to reproduce: Install Beta 44, (or even the last Developer 44 from https://archive.mozilla.org/pub/firefox/nightly/2015/12/2015-12-14-00-40-08-mozilla-aurora/) and a copy of the latest developer version (If prefferable) Install session manager, and create a 400+ tab session containing anything you like Exit and restart to a fresh start, and restore the session, benchmark the startup time and note the memory use Repeat with 'Firefox' 45, note the higher memory usage on the Firefox.exe process and the increase in time it takes to restore the session. Actual results: Developer edition Firefox.exe (45) memory 2-3x higher compared to Firefox.exe Beta (44) Startup time also massively increased due to hanging up the host process. Expected results: Good question.... From what I seem to be seeing, a change has been made where tab information is now being stored in the main process, which is contributing to rather long session restore times. Where as in Firefox 44, the tab information is being processed by the ipc container, and doesn't jank up the host process. This is thoroughly reproducible by moving between https://archive.mozilla.org/pub/firefox/nightly/2015/12/2015-12-14-00-40-08-mozilla-aurora/ and https://archive.mozilla.org/pub/firefox/nightly/2015/12/2015-12-15-00-40-11-mozilla-aurora/
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
¡Hola Danial! Could you please capture and provide the data detailed at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem ? ¡Gracias!
QA Whiteboard: [bugday-20151228]
I don't have the time to be doing the work that Mozilla developers should be doing themselves. The issue i have noted is due to the main process handling the restoration of all tab information instead of having the ipc container doing it. Plugin container process does not open until the session has fully loaded and the first selected tab has restored, compared to 44 where the plugin container process is opened and does the majority of the work - (which takes mere seconds with a non-default ipc process count) but with the 45 behavior the ipc process(es) don't get to do any of the work until the session is loaded and tabs restored)
Summary: Performance Down, Memory use Up in Firefox 45 → e10s regression - Session Restore Performance Down, Memory use Up in Firefox 45 (Tab restore processed by Firefox.exe intead of plugincontainer.exe)
¡Hola Mike! Does this sound like a valid NEW bug to you or is it a DUPLICATE? ¡Gracias!
tracking-e10s: --- → ?
3 years ago
Component: Untriaged → Session Restore
I assume since you're talking about IPC, this bug is restricted to e10s mode. Bug 1209689 landed on 45 which might cause what you're describing. Before that bug landed, we were loading unrestored background tabs in the content process on session restore. With bug 1209689 landed, we now load them in the parent process in the background (so as to avoid having to deal with unrestored background tabs crashing). This was caught by our talos regression suite in bug 1227275 where I argued the case for keeping the bug landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1227275#c6. TL;DR - yes, large session restore will demand more from the parent process in 45 with e10s than in 44 with e10s. However, both are strictly better than with non-e10s.
I'm hoping to revisit bug 1227275 and finding a way of dealing with the crashed unrestored background tab case in a sane way. Regardless, I'm confident that this is a dupe of bug 1227275.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1227275
Thanks Mike, i figured talos caught it but couldn't find the bug in search.
You need to log in before you can comment on or make changes to this bug.