I have 25 tabs open, mostly Bugzilla and etherpad pages. When e10s autostart is enabled, restoring my session takes about 40–60 seconds. When e10s autostart is not enabled, session restore takes only 20 seconds. I'm testing over Wi-Fi (at home and Mozilla office Wi-Fi).

btw, my browser.sessionstore.restore_on_demand pref is false, so session restore is actually loading all those tabs' content.

Is this just limited to session restore? i.e. Does it take longer when opening multiple tabs at once (that are opened quickly or) from a bookmark open all. See also bug #1091733

Read bug #666365 A hunch tells me it maybe a big factor in the slowdown.

Same for Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141119030200 CSet: b4fbeba78a7d

blake, we have a session restore talos test. any idea hwo we're doing there under e10s?

If bug 1250620 comment 4 is accurate (and I believe it to be), we have equal (if not slightly better) performance against non-e10s on talos.

Also note that this was filed back in 2014 - a lot of work has been done to reduce the amount of set-up and sync messaging that occurs during session startup. cpeterson, you don't still see anything this bad, do you?

I don't think this bug is fixed. I retested four times, opening 41 tabs in Nightly 47, and e10s is still at least 1.7x slower (when I set browser.sessionstore.restore_on_demand = false): * without e10s = 158 seconds * without e10s = 165 seconds * with e10s = 297 seconds * with e10s = 261 seconds (almost 5 minutes!) When I filed this bug against FF 33 in 2014, session restore of 25 tabs only took 20 seconds with e10s disabled! To be fair, my 2016 test of 41 tabs included 18 Google Docs, whereas I'm sure my 2014 test had no Google Docs.

Re-nomming to get prioritized in the e10s-perf work.

Yikes, I still had a needinfo here! I haven't had a chance to look at these Talos tests, yet. Jonathan, have you looked at them at all?

(In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #10) > Yikes, I still had a needinfo here! I haven't had a chance to look at these > Talos tests, yet. Jonathan, have you looked at them at all? Avi, can you confirm that the sessionrestore Talos tests shows similar performance for e10s vs non-e10s?

Unfortunately, I'm blocked in my rewriting-Talos-test-to-make-them-show-meaningful-e10s-values by addon signature and some unknown (Talos?) bug. I currently cannot run my testing code locally, at all, which makes it really grinding. I will try with the patch of bug 1253736.

(In reply to Jonathan Griffin (:jgriffin) from comment #11) > (In reply to Blake Kaplan (:mrbkap) (please use needinfo!) from comment #10) > > Yikes, I still had a needinfo here! I haven't had a chance to look at these > > Talos tests, yet. Jonathan, have you looked at them at all? > > Avi, can you confirm that the sessionrestore Talos tests shows similar > performance for e10s vs non-e10s? Currently, yes, similar enough. See the live dashboard here https://treeherder.allizom.org/perf.html#/e10s TL;DR: very similar, except on session_restore OS X is ~2% worse on e10s (very minor), and on session_restore_no_auto_restore linux and XP are ~4.5% better on e10s.

Jeff, this is a bad regression in a non-default session restore setting. should it block?

We noted in the meeting that this is a pref we expose in our pref UI: "Don’t load tabs until selected" in the main pref page.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #15) > We noted in the meeting that this is a pref we expose in our pref UI: "Don’t > load tabs until selected" in the main pref page. Sure, but what % of the population has this pref toggled?

That is not currently recorded. I'm fine if you're thinking of removing support for that pref entirely. What I don't want to do is ship a serious regression in a supported config just because it affects a small number of people.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #17) > That is not currently recorded. > > I'm fine if you're thinking of removing support for that pref entirely. What > I don't want to do is ship a serious regression in a supported config just > because it affects a small number of people. In the absence of data, that's exactly what we're going to do. This is P1, it's important, but we're not blocking on it. The workaround is to restore the default preference.

(In reply to Chris Peterson [:cpeterson] from comment #8) > I don't think this bug is fixed. I retested four times, opening 41 tabs in > Nightly 47, and e10s is still at least 1.7x slower (when I set > browser.sessionstore.restore_on_demand = false): How are you measuring when restoring a session is finished? > * without e10s = 158 seconds > * without e10s = 165 seconds > * with e10s = 297 seconds > * with e10s = 261 seconds (almost 5 minutes!) I'd be a bit concerned that this might not have anything to (directly) with session restore, and is instead an indication that E10S is slower at loading multiple pages in parallel. Session restore w/o on-demand loading would obviously hit that, but so would other things. (EG opening a bunch of links from a page in background tabs). Do we have any data to indicate this is actually specific to session-restore, as opposed to a general load-pages-in-parallel issue? How about bookmarking those pages into a folder, and performing "Open All In Tabs"? (In reply to Avi Halachmi (:avih) from comment #13) > > Avi, can you confirm that the sessionrestore Talos tests shows similar > > performance for e10s vs non-e10s? > > Currently, yes, similar enough. See the live dashboard here > https://treeherder.allizom.org/perf.html#/e10s > > TL;DR: very similar, except on session_restore OS X is ~2% worse on e10s > (very minor), and on session_restore_no_auto_restore linux and XP are ~4.5% > better on e10s. Hmm, I see sessionrestore there being a 400-500% regression on all platforms. Oh, but this is a mozilla-inbound regression starting March 15th. Is that tracked somewhere? It seems odd that Talos is saying there's no sessionrestore issue, whereas cpeterson is seeing something.

(In reply to Justin Dolske [:Dolske] from comment #19) > (In reply to Chris Peterson [:cpeterson] from comment #8) > > I don't think this bug is fixed. I retested four times, opening 41 tabs in > > Nightly 47, and e10s is still at least 1.7x slower (when I set > > browser.sessionstore.restore_on_demand = false): > > How are you measuring when restoring a session is finished? I'm measuring wall clock time until every tab's spinner stops spinning. > It seems odd that Talos is saying there's no sessionrestore issue, whereas > cpeterson is seeing something. Does the sessionrestore test set browser.sessionstore.restore_on_demand = false? > Do we have any data to indicate this is actually specific to > session-restore, as opposed to a general load-pages-in-parallel issue? How > about bookmarking those pages into a folder, and performing "Open All In > Tabs"? Good question, so I just tested e10s and non-e10s with Nightly 48, Aurora 47, and Beta 46 loading 60 tabs (the sites linked to from Hacker News' top 60 stories). I think this is an e10s networking problem with page load stampede, in general, and not specifically session restore. e10s is about 1.5x – 2x slower than non-e10s for both session restore and "open all in tabs"... except for Nightly 48, which may be confirmation of the session restore regression reported by Talos. Session restore and "open all in tabs" times are roughly the same when comparing e10s-to-e10s and non-e10s-to-non-e10s. While watching the tab spinners, I noticed that session restore only load three tabs at a time, while "open all in tabs" seems to have no parallelism limit and loads 10–20 tabs simultaneously. FF48 session restore without e10s = 115s // Confirmation of the session restore regression reported by Talos? FF48 session restore with e10s = 107s // 0.9x (faster) FF48 open all in tabs without e10s = 79s FF48 open all in tabs with e10s = 171s // 2.2x slower FF47 session restore without e10s = 79s FF47 session restore with e10s = 115s // 1.5x slower FF47 open all in tabs without e10s = 82s FF47 open all in tabs with e10s = 114s // 1.4x slower FF46 session restore without e10s = 104s FF46 open all in tabs without e10s = 126s

(In reply to Justin Dolske [:Dolske] from comment #19) > Hmm, I see sessionrestore there being a 400-500% regression on all > platforms. Oh, but this is a mozilla-inbound regression starting March 15th. > Is that tracked somewhere? Bug 1245891 changed how the Talos tests measure session restore time, so this is not a regression, as per bug 1245891 comment 48. For reference, here is the graph of the Talos "regression": https://treeherder.allizom.org/perf.html#/graphs?series=%5Bmozilla-inbound,ebc60b2c69a8a5931274e365c4b3ed0650bf12db,1%5D&series=%5Bmozilla-inbound,7c1f3a79275eb6b31e4360bbd300472def25d022,1%5D&selected=%5Bmozilla-inbound,7c1f3a79275eb6b31e4360bbd300472def25d022,21005,21165652%5D

Chris, sorry, but when you are about to blame networking from this, you need to provide some specific data to support it.

(In reply to Chris Peterson [:cpeterson] from comment #20) > > It seems odd that Talos is saying there's no sessionrestore issue, whereas > > cpeterson is seeing something. > > Does the sessionrestore test set browser.sessionstore.restore_on_demand = > false? Hmm, I assumed so, since there's a "sessionrestore_no_auto_restore" test too. But from looking at testing/talos/talos/test.py it seems that's just measuring time time to parse the old session but not restore anything. I don't see anything in the Talos test profile or bug 1245891 that indicates it's setting this, so it seems the regular sessionrestore test is not actually measuring the time to load any tabs (other than whatever tab is selected). Yoric, is this intentional? (In reply to Chris Peterson [:cpeterson] from comment #21) > (In reply to Justin Dolske [:Dolske] from comment #19) > > Hmm, I see sessionrestore there being a 400-500% regression on all > > platforms. Oh, but this is a mozilla-inbound regression starting March 15th. > > Is that tracked somewhere? > > Bug 1245891 changed how the Talos tests measure session restore time, so > this is not a regression, as per bug 1245891 comment 48. Hmm, no, my reading is just that the test is measuring a different (more complete) potion of session restore, and so the numbers were not expected to be the same as what the old test reported. And that's what Avi is saying in bug 1245891 comment 45. That the numbers went up is not surprising... That there's a large difference between E10S and non-E10S is, and would indicate that there's a real problem here. (Or that the test is broken, the *decrease* on non-E10S compared to the old test is surprising.) (In reply to Chris Peterson [:cpeterson] from comment #20) > Session restore and "open all in tabs" times are roughly the same when > comparing e10s-to-e10s and non-e10s-to-non-e10s. While watching the tab > spinners, I noticed that session restore only load three tabs at a time, > while "open all in tabs" seems to have no parallelism limit and loads 10–20 > tabs simultaneously. This is throttled by MAX_CONCURRENT_TAB_RESTORES in SessionStore.jsm. Unfortunately there's no longer a pref to control it, but you could do a custom build to set it to a large value. Or maybe hack it at runtime with the devtools, and measure doing a session restore manually (eg from the button on about:home). > FF48 session restore without e10s = 115s // Confirmation of the session > restore regression reported by Talos? > FF48 session restore with e10s = 107s // 0.9x (faster) > > FF48 open all in tabs without e10s = 79s > FF48 open all in tabs with e10s = 171s // 2.2x slower > > FF47 session restore without e10s = 79s > FF47 session restore with e10s = 115s // 1.5x slower > > FF47 open all in tabs without e10s = 82s > FF47 open all in tabs with e10s = 114s // 1.4x slower Multiple issues to unpack here! Let me try and summarize: * Your testing indicates real-world session restore in FF48 actually faster for E10S vs not-E10S. This is good news, let's ship E10S! * Your testing indicates non-E10S session restore regressed from FF47 to FF48. The is not good news. It also indicates that while FF48-E10S is faster than FF48-non-E10S, it's still slower than FF47-non-E10S. Also not good news. Assuming your results are reproducible and consistent, we should have a bug to investigate what happened here. Not an E10S specific issue, but is a general Firefox regression. * Your "open all in tabs" testing indicates that there is a significant performance regression with loading multiple tabs with E10S. Not entirely sure what to make of this, it might imply that benefits of E10S dominate when loading small number of tabs in parallel, but costs of E10S dominate when loading large numbers of tabs in parallel? I'd suspect the former is more important, so this might be a fine tradeoff. * Talos (as of bug 1245891) indicates that part of session restore has regressed significantly for E10S. The old test didn't show a difference, and the new test (also) doesn't measure content load, so this may effectively be a measurement of the cost of opening a tab? Although the Talos tabpaint tests all seem equal-to-better for E10S, so this also needs further investigation.

There is concern that the new Talos test for Session Restore might be wrong. I haven't had time to look at this yet, but I'll try and do it this week.

(In reply to Justin Dolske [:Dolske] from comment #19) > Hmm, I see sessionrestore there being a 400-500% regression on all > platforms. Oh, but this is a mozilla-inbound regression starting March 15th. > Is that tracked somewhere? This is tracked by bug 1259770.

I decided to do some measurements after reading comment 20 so here is the results: Firefox 47, uBlock and Tab Mix Plus installed, everything blocked in uBlock except for images and 3rd party. I open 9 tabs [Group A], wait until they load and then start loading a new bookmarked group of tabs [Group B] using "Open all in tabs". Then I measure two things: 1. How long it takes before tabs from Group A are readable (strobbler with e10s/white page without e10s disappears) 2. How long it takes to load all tabs from Group B. After that I restart the browser and repeat the cycle with a new Group B with different number of tabs. Results: e10s enabled, 52 tabs with text: 10 seconds before Group A is readable, 70sec before Group B is loaded e10s disabled, 52 tabs with text: 3 seconds before Group A is readable, 60sec before Group B is loaded e10s 3 times slower, 1.16 times slower e10s enabled, 52 tabs with text+thumbnails: 20 seconds before Group A is readable, 60 seconds before Group B is loaded e10s disabled, 52 tabs with text+thumbnails: 6 seconds before Group A is readable, 35 seconds before Group B is loaded e10s 3 times slower, 1.7 times slower e10s enabled, 107 tabs with text: 100 seconds before Group A is readable, 320+ seconds before Group B is loaded e10s disabled, 107 tabs with text: 16 seconds before Group A is readable, 180 seconds before Group B is loaded e10s 6 times slower, 1.77 times slower e10s enabled, 103 tabs with text+thumbnails: 240 seconds before Group A is readable, 420+ seconds before Group B is loaded e10s disabled, 103 tabs with text+thumbnails: 20 seconds before Group A is readable, 120 seconds before Group B is loaded e10s 12 times slower (!!!), 3.5+ times slower Conclusion: big performance degradation with e10s when opening big number of tabs, HUGE performance degradation with e10s when opening big number of tabs with many thumbnails. PS. Why do I need to load 100 tabs at once? I like to restore sessions this way: it is more convenient to wait a minute before all tabs are loaded and have quick access to any of them afterwards. But it looks like that after e10s lands I'll have to limit the number of concurrent loading tabs somehow and wait a lot longer.

curious if there is an update to status/priority of this bug? It seems related to bug 1192585 - and with e10s going to more add-ons... this issue will become more visible. I am manually blocking TMP from getting e10s for now (in Beta 51) - but we will want to enable that soon.

(In reply to :shell escalante from comment #27) > curious if there is an update to status/priority of this bug? It seems > related to bug 1192585 - and with e10s going to more add-ons... this issue > will become more visible. I am manually blocking TMP from getting e10s for > now (in Beta 51) - but we will want to enable that soon. Shell, thanks for raising this. We removed the user-facing option to restore all tabs in bug 1257554, and the idea behind the removal was to minimize the number of users that could possible enable this option because restoring all tabs on launch is a performance disaster. I would be interested to know specifically if there are large numbers of people with this pref enabled, and if that correlates to tab mix plus users. Unless there is a lot of user impact here this is low priority.

Latest Tab mix developer build from 2015-12-25 have a new option to open unloaded bookmarks. Read explanation in Tab Mix help page: http://tabmixplus.org/support/viewpage.php?t=3&p=events-new-tabs Tab mix uses Sessionstore to load the tabs Check this version with the new options enabled and report if you see an improvement

Mass wontfix for bugs affecting firefox 52.

Maybe relevant, from <https://github.com/kesselborn/conex/issues/48#issuecomment-335016004> for Firefox 56.0: > … I prepared for a trouble-free third session by adding boolean `browser.tabs.remote.force-disable` – `true` – before the launch of Firefox. … – but please note that import is not a core feature of Conex. Also my Firefox is on a significantly outdated (and Tier-3) FreeBSD-CURRENT; and 56 is below what's properly supported by Conex. ---- Still, I reckon that what's above is worth mentioning, because I had previously gained a sense (with 55.x, without Conex) that things sometimes became 'tricky' on the rare occasions when I allowed e10s. Yeah, I know, that's too vague to be actionable :-) sorry …

With Firefox 57 only WebExtensions are permitted and are, by default, e10s compatible.