1235214 - e10s regression - Session Restore Performance Down, Memory use Up in Firefox 45 (Tab restore processed by Firefox.exe intead of plugincontainer.exe)

Status: RESOLVED DUPLICATE of bug 1227275

(Firefox :: Session Restore, defect)

Description

[Danial Horton]

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/

Comment 1

[alex_mayorga]

¡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!

Comment 2

[Danial Horton]

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)

Comment 3

[alex_mayorga]

¡Hola Mike!

Does this sound like a valid NEW bug to you or is it a DUPLICATE?

¡Gracias!

Comment 4

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 6

[Danial Horton]

Thanks Mike, i figured talos caught it but couldn't find the bug in search.