Open Bug 582005 Opened 10 years ago Updated 1 month ago
Session Restore negatively impacts startup time based on the number of tabs loaded
Session restore appears to have a noticeable hit on startup time that scales with the number of tabs it restores. This is not related to the load time of each tab because all I ever see on the scree is a white window area while it adds all the tabs. We should really really fix this.
This is bad and should be treated as a blocker whether or not we decide to flag it. We need ux support here on deciding the right approach, too, since it will almost certainly involve some user-visible changes on top of any technological ones. Limi: who's our contact for this work?
Paul: a suggestion - feels like what this bug should be is on developing a plan (and filling follow up bugs) which will result in measurable improvements. That plan itself would likely block something like beta4, and then we can make decisions about each of the follow up bugs.
I'll need to look into it, but I'm curious to see how much of this is session restore itself and how much is just overhead from opening tabs. I started doing some ss profiling long ago but other things took precedence. I'll assume Shawn is right & the slowdown isn't related to the load of those other pages, so that leaves the overhead from creating the tab, or what sessionstore does with the tab after that (which is mostly just adding the entries to session history & adding cookies). So yea, it'll require a bit of investigation and we can make this a planning/tracking bug. I'd be more than happy if the problems were contained to session restore, but... I'm a bit skeptical (and biased).
OS: All → Windows 7
Hardware: All → x86
OS: Windows 7 → All
Hardware: x86 → All
I think Limi put his hand up manage the UX here, is that right? If so, can we get an outline of the experience zpao should be creating?
I think comment 4 is presuming a solution! :) My feeling is that we should do a few things: 1. Determine the Ts overhead from every additional tab 2. Figure out if some form of optimization can eliminate the majority of the Ts drain while still restoring all tabs 3. Figure out what the UX should be for various possibilities: lazy-restore, restore-all-on-click, do nothing until click, etc.
Approving blocking request to keep it on the front-burner. If we figure out optimizations or UX approaches, we can move the blocker-ness over to those bugs.
blocking2.0: ? → betaN+
I'm not sure if this is the right bug, but I'm hoping at some point that Firefox will: * prioritize and load the focused tab of the focused window first, and as fast as possible, instead of loading tabs in any old order which makes Session Restore feel horribly slow(!) * save the title of webpages so that restoring tabs can be given their title text immediately, instead of only getting their titles after the page they contain starts to load - this would allow the user to switch to the tab they care about immediately without having to wait when restoring a session; which leads on to... * if the user does switch to a different tab during session restore, re-prioritize tab loading and load the new focused tab as fast as possible I would guess none of this would affect Ts since I assume Ts doesn't count loading of content, but these changes would no doubt do a lot more for user perception of the speed of Session Restore than any Ts wins we can achieve (as great as they would be of course!).
This might be related to another bug where the user interface of Firefox does not draw until all tabs from the session store is loaded. My guess is it basically deadlocks the main thread of Firefox until all tabs are loaded.
(In reply to comment #7) > I'm not sure if this is the right bug, but I'm hoping at some point that > Firefox will: Not the right bug, but that's ok. > * prioritize and load the focused tab of the focused window first, > and as fast as possible, instead of loading tabs in any old order > which makes Session Restore feel horribly slow(!) We do that. > * save the title of webpages so that restoring tabs can be given > their title text immediately, instead of only getting their titles > after the page they contain starts to load - this would allow the > user to switch to the tab they care about immediately without > having to wait when restoring a session; which leads on to... We do save that. We don't currently show it though (because each tab is actually loading) > * if the user does switch to a different tab during session restore, > re-prioritize tab loading and load the new focused tab as fast as > possible That *should* be happening already. It might be hard to detect when we're already saturating your network though. If you're interested, you might want to follow along in bug 586068.
Ok so I did a little profiling (I'll attach my profiling patch soon). This measurement is as of the last tab "loading" - in which we run restoreDocument. The results so far indicate that most of the time is spent waiting for the load events. Shawn says the Ts test isn't related to actually loading things, but if adding more tabs causes tLoadAvg to increase (which it does) then it could well be related. I'm going to set up standalone talos and see if I get a better idea. I did this profiling with a few different numbers of tabs (kept it to one window because I haven't written this to handle that). It looks like there's a pretty consistent 20-30ms increase in "Time to create tabs ~t" (t=total, just measuring around the loop that calls gBrowser.addTab. Sample output from 2 tabs: ///// restoreDocument ///// Time to firstLoad: 1320 Time to lastLoad: 1398 Time to notify: 109 Time to create tabs ~t: 31 Time to create tabs ~r: 45 Time to end: -- tRestoreHistoryAvg: 10 tRestoreHistoryArr: [13,7] tRestoreDocumentAvg: 4 tRestoreDocumentArr: [6,2] tLoadAvg: 1217 tLoadArr: [1209,1225] Num Windows: 1 Num Tabs: 2 (you can ignore "Time to end" - nothing is actually measuring that)
(In reply to comment #9) > (In reply to comment #7) > We do that. Oh, cool. I must have been encountering the bad behavior when running old versions. > We do save that. We don't currently show it though (because each tab is > actually loading) Could we show the loading title until it's overwritten by the loading content? > That *should* be happening already. It might be hard to detect when we're > already saturating your network though. I need to retest making sure I'm using a recent beta. > If you're interested, you might want to follow along in bug 586068. Thanks!
Shawn's numbers he gave me showed a pretty consistent 200ms per 8 tabs added, which comes out to 25ms per tab, which fits right in my 20-30ms increase in "Time to create tabs ~t". This isn't necessarily the only point of slowdown, but there's definitely a correlation (does it imply causation?). I don't think there's a whole lot to do here beyond optimizing gBrowser.addTab.
This bug needs to go pretty quickly if it's going to change our session restore UI in time to get beta coverage, and I think making real progress will require that. Can we get linkage to the plan from UX as to how this should work/feel? And ETA on a patch, perhaps?
Not sure what UI is going to change in direct relation to this, unless we delay creating tabs, which doesn't seem like a good idea. I have bug 586068 for cascading loads, but I don't think that's going to have any direct impact on any Ts measurement. If anything, it might slow down the actual time it takes to load all tabs (but the browser should be more usable in the interim).
Can you attach your profiling patch? The session restore code uses the external APIs of the tabbrowser like any other consumer of it. It sounds maybe we should investigate tighter integration, or perhaps specialized APIs such as one to open N tabs in bulk.
Depends on: 588482
With bug 586068 and bug 588482 resolved, I believe the remaining work here no longer blocks. However, this bug is not resolved, either. We pay a substantial (20-30ms) cost for each tab creation, and that feels like a number that could (and should) be reduced with some profiling and cleanup.
blocking2.0: betaN+ → -
One other solution to this bug would be to make "Don't load tabs until selected" the default when "show my windows and tabs from last time" is active. This makes an enormous performance advantage for my x-hundred tabs usage. IMHO "show my windows and tabs from last time" is also a better default than "show my home page" since that already and only loads the last used tab from the last session. The chance is probably high you want to visit this first. And even if not you can directly choose the tab you need with out loading all other tabs (if "Don't load tabs until selected" is active).
Stefan, there's bug 711193 about your solution :D. However this bug should be about improving startup time when "Don't load tabs until selected" isn't active.
I'm doing some profiling of a 364 tab session (~60 in the active group) right now, and even with tabs-on-demand enabled it's taking up to 5 seconds just create the xul tabs: bug 715612.
Depends on: 715612
Not working on this, but it's pretty similar to the other session restore related perf bugs, so CCing Tim as he's sort of keeping an eye on those.
Assignee: paul → nobody
Measured again after some time has passed and we're (unsurprisingly) still quite bad at restoring lots of tabs. My session contains about 250+ tabs and takes a lot more time to restore (1445ms) then just a single tab (16ms). I measured the restoreWindow() call in onLoad() which restores the initial state. restoreHistoryPrecursor() took about 475ms to restore the tabs' histories etc. That leaves about a second for all the gBrowser.addTab(), hideTab(), pinTab() calls in restoreWindow(). There are a couple of things we could do to improve this. We could for example have a method that somehow creates all these tabs in a DocumentFragment, inserting them into the DOM at once. Properties like "hidden", "pinned", or "pending" should also be set before those tabs are injected.
If that helps, I experience the very same issues in the recent versions of Firefox (including Nightly up to today’s v38.0) on OS X 10.10.1 (latest) and a MacBookAir 2014. My Firefox profile is now 4 weeks old and with extensions the issues are more serious (have 3 extensions active usually) but they appear also without any active extension. In the recent weeks it often happened that I needed to force quit Firefox until I could restore sessions again without Firefox getting in a serious performance issue and hung up (so the only way was force quitting FF). Mostly after 3x restarting Firefox the Restore Sessions worked again although it was super slow. Tab Restore Times for about 50 tabs (I assume this is ms in telemerty report): - sessionRestoreInit 426 - sessionRestoreRestoring: 1520 - sessionRestored: 3047 - firstLoadURI: 3110 I had as horrible times as waiting about 60 seconds or more before I was able to work with Firefox after restoring tabs. I’m not sure if it’s related but my shutdown of Firefox also takes from shutdownDuration: 7600ms up to 38530ms, depending on how many tabs were open and how long the session was open. This is quite horrible performance and I’d love to see this resolved. All of it by the way without e10s as disabled by accessibility tools. Let me know if you need more data and I’ll try to capture it for you.
(In reply to info from comment #24) > In the recent weeks it often happened that I needed to force quit Firefox > until I could restore sessions again without Firefox getting in a serious > performance issue and hung up (so the only way was force quitting FF). > Mostly after 3x restarting Firefox the Restore Sessions worked again > although it was super slow. > I had as horrible times as waiting about 60 seconds or more before I was > able to work with Firefox after restoring tabs. > > I’m not sure if it’s related but my shutdown of Firefox also takes from > shutdownDuration: 7600ms up to 38530ms, depending on how many tabs were open > and how long the session was open. I’ve identified the Buffer extension to be reponsible for these startup crashes and heavy delays. This said, it’s still not very fast. The telemerty results above were with addons disabled.
You need to log in before you can comment on or make changes to this bug.