My biggest TSnap issue: session restore
Benjamin Smedberg
there are a couple places where Firefox feels really slow.
The first is really large hangs caused by session-restore. We both typically
leave our browser up all the time with several apps such as webmail, as well
as a selection of webpages. Launching Firefox after the computer reboots or
an update is applied is horribly slow-feeling because all those pages are
loading at once and the UI is basically non-responsive during the initial
part of that.
It seems to me that session-restore could be a lot smarter about loading pages:
* create the UI for all the windows and tabs, but only start loading the
webpage in the one which is on top
* Delay loading other tabs until the first one is mostly done
* Only load a few at a time
I think fixing this might help user perception a lot: when session restore
happens the user is obviously trying to get things done right away (they
just launched Firefox) and they might already be annoyed that their computer
crashed, or Firefox crashed, or an update was installed, or whatever.
(The other TSnap problem is huge hangs caused by Weave, but that's probably
not relevant to this list.)
--BDS
Mike Beltzner
> It seems to me that session-restore could be a lot smarter about
> loading pages:
>
> * create the UI for all the windows and tabs, but only start loading
> the
> webpage in the one which is on top
> * Delay loading other tabs until the first one is mostly done
> * Only load a few at a time
Something very much along these lines has already been done (on trunk
and in 3.5):
https://wiki.mozilla.org/Firefox/Sprints/Restore_Visible_Tabs_First
https://bugzilla.mozilla.org/show_bug.cgi?id=480148
Paul noted that the effect was there, but not as visible as we'd
initially hoped. I think we can do a second iteration where instead of
prioritizing "visible" tabs in each window, we prioritize the focused
tab and then the visible tabs.
cheers,
mike
Benjamin Smedberg
> Paul noted that the effect was there, but not as visible as we'd
> initially hoped. I think we can do a second iteration where instead of
> prioritizing "visible" tabs in each window, we prioritize the focused
> tab and then the visible tabs.
Yeah, I feel this a lot with nightly updates so I'm really hoping something
more can be done. Even just prioritizing the network loads of the main tab
over all the others (if that's possible?) would be really useful.
--BDS
Mike Beltzner
Totally agree, and I do suspect that in many cases we're getting
limited by the maximum number of http connections (30, by default).
Jason, any idea if we can prioritize the network loads as bsmedberg
suggests?
cheers,
mike
Boris Zbarsky
> Totally agree, and I do suspect that in many cases we're getting limited
> by the maximum number of http connections (30, by default). Jason, any
> idea if we can prioritize the network loads as bsmedberg suggests?
Yes. You can get the loadgroup from that tab's docshell, QI it to
nsISupportsPriority and bump it up in priority. That will give that
same bump to all loads in that loadgroup.
To get the loadgroup, QI the tab's webnavigation to nsIDocumentLoader.
Just remember to reset the priority back to default at some point.
-Boris
Dan Mills
Curious--Can you try updating to our latest snapshot and seeing if that
improves the Weave hangs? We have more work to do, but 0.5pre2 has some
recent improvements.
Dan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Alexander Limi
I did file a "Perceived Performance" bug for this a while back:
https://bugzilla.mozilla.org/show_bug.cgi?id=496458
And I agree, it's one of the most visible things we can do to make Firefox
feel faster.
--
Alexander Limi · Firefox User Experience · http://limi.net