My biggest TSnap issue: session restore

10 views
Skip to first unread message

Benjamin Smedberg

unread,
Jul 17, 2009, 9:47:09 AM7/17/09
to
From my own use of Firefox, and watching my wife using it on her computer,
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

unread,
Jul 17, 2009, 10:42:42 AM7/17/09
to Benjamin Smedberg, dev-apps...@lists.mozilla.org
On 17-Jul-09, at 9:47 AM, Benjamin Smedberg wrote:

> 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

unread,
Jul 17, 2009, 10:51:44 AM7/17/09
to
On 7/17/09 10:42 AM, Mike Beltzner wrote:

> 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

unread,
Jul 17, 2009, 11:05:04 AM7/17/09
to Jason Duell, dev-apps-firefox List

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

unread,
Jul 17, 2009, 11:21:16 AM7/17/09
to
Mike Beltzner wrote:
> 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

unread,
Jul 17, 2009, 2:44:10 PM7/17/09
to Benjamin Smedberg, Weave Dev List, dev-apps...@lists.mozilla.org
Cc'ing Weave dev list.

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

unread,
Jul 21, 2009, 7:52:19 PM7/21/09
to Benjamin Smedberg, dev-apps...@lists.mozilla.org

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

Reply all
Reply to author
Forward
0 new messages