591704 - [meta] Loading the Panorama (tab view) view can be very slow with many tabs

Status: RESOLVED FIXED

(Firefox Graveyard :: Panorama, defect, P1)

Description

[Michael Yoshitaka Erlewine [:mitcho]]

Fix it!

Comment 1

[Emmanuel Lepage Vallee]

Confirmed. With many tabs, animations are non-existant and speed go to an halt. This problem is true for Firefox as a whole, not just for Panorama. Isolating the main JS thread from the Interface JS thread would fix the problem. It does not even need full JS multithreading, just a second thread just for the gui.
I

Comment 2

[Michael Yoshitaka Erlewine [:mitcho]]

(In reply to comment #1)
> Confirmed. With many tabs, animations are non-existant and speed go to an halt.
> This problem is true for Firefox as a whole, not just for Panorama. Isolating
> the main JS thread from the Interface JS thread would fix the problem. It does
> not even need full JS multithreading, just a second thread just for the gui.
> I

Actually, as noted in my comments on bug 591709, it looks like the limiting factor here seems to be waiting for the session store to restore the tab data, not synchronicity.

Comment 3

[The 8472]

I suggest the following setup for testing:

-Direct 2D enabled
-image.mem.decodeondraw = true
-image.mem.discardable = true
-100-200 tabs with big or many images open (opening a large bunch of flickr galleries should do the job)

I've experienced severe slowdowns with this configuration and and occasional freezes in firefox (not just inside tabcandy), but i cannot test if it's due to tabcandy or not since there is no option to disable it.

Comment 4

[John Bird]

Tabcandy is most useful for large numbers of tabs, but performance degrades significantly with larger numbers of tabs.

-On restart of Firefox the Panorama/Group your Tabs page paints the tabs about 1-3 per second, for 150+ tabs this is too long - 50 seconds .   From Ian Gilman I understand this is because Firefox renders each tab to get the thumbnail. As thumbnails are tiny - probably 1-5K I suggest that thumbnails are generated when a page is rendered, and saved on exit, and the thumbnail directly loaded on restart.

-Target should be for Panorama page to paint at similar speed to any other web page - 1 to 5 seconds.

-Numerous events seem also to interrupt painting of the Panorama page - a PDF open in a tab is one, or a modal dialog saying "A script on this page is not responding - wait or continue"  (this can come about when lots of tabs are opening at once)

-Some tabs do not get loaded sometimes - seems to be the last ones opened, these can get "lost"  in bottom right of screen not in a group.

-(Related) the Bartab extension is not fully compatible - this unloads inactive tabs using the session manager, and TabCandy loads a lot faster with Bartab enabled, but does not always get all tabs - some of the disabled/unloaded tabs do not get loaded.

Comment 5

[Michael Yoshitaka Erlewine [:mitcho]]

John, this is a meta (tracking) bug so I encourage you to create multiple bugs for specific action items or bugs and mark them as blocking this bug. I believe bugs exist for some of the issues you mentioned.

Comment 6

[Michael Yoshitaka Erlewine [:mitcho]]

Requesting blocking final+.

Comment 8

[Johnathan Nightingale [:johnath]]

(In reply to comment #6)
> Requesting blocking final+.

I'll go you one better - we should make these changes in time to get beta feedback on them - blocking betaN+.

Comment 9

[David Dahl :ddahl]

(In reply to comment #2)
> Actually, as noted in my comments on bug 591709, it looks like the limiting
> factor here seems to be waiting for the session store to restore the tab data,
> not synchronicity.

Sorry to spam your tracking bug, but my experience seemed to not have to do with session restore. I restarted my browser hours before I invoked panorama with maybe 25 tabs. It took a few good seconds to render the UI. 

I have not since seen that happen again, perhaps my browser was busy expiring places records or syncing, you never know. Also, this was on a dual-core 1.6 Ghz thinkpad.

Comment 10

[Aza Raskin [:aza]]

It may be worth using the idea presented in 591912 to help accomplish this goal. That is, load groups which are larger before groups that are smaller.

Comment 11

[Kevin Hanes]

Beta8 has 1 bug left on it, moving our blockers to b9

Comment 12

[Ian Gilman [:iangilman]]

Do we still need this meta bug, or should we roll it into bug 604213?

At any rate, we've already made progress in this area; not sure how to know when it's good enough.

Comment 13

[Benjamin Smedberg]

Not blocking on meta bugs. Please nominate particular deps as necessary.

Comment 14

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Has anybody profiled this?  Are we spending all of our time encoding images?  It doesn't seem that this has been investigated much and it's still pretty slow.

Comment 15

[Ian Gilman [:iangilman]]

(In reply to comment #14)
> Has anybody profiled this?  Are we spending all of our time encoding images? 
> It doesn't seem that this has been investigated much and it's still pretty
> slow.

I don't know that anyone's done formal profiling on it. 

It wouldn't be generating the thumbnails from the pages, as that happens as a periodic process outside of the loading sequence. It could be instantiating all of the cached thumbnails, however, or it could be creating all of the DOM elements.

Comment 16

[Kevin Hanes]

bugspam (moving b9 to b10)

Comment 17

[Kevin Hanes]

bugspam (removing b9)

Comment 18

[Tim Taubert [:ttaubert] (inactive)]

Attachment: Chromebug profiler report of UI.init()

(In reply to comment #15)
> I don't know that anyone's done formal profiling on it. 
> 
> It wouldn't be generating the thumbnails from the pages, as that happens as a
> periodic process outside of the loading sequence. It could be instantiating all
> of the cached thumbnails, however, or it could be creating all of the DOM
> elements.

I profiled this today with chromebug and attached the report as a PDF file. These are the results (using UI.init() as starting point) having 5 tabs opened in 2 tab groups. Note that at least some of the TabCanvas.paint() calls are synchronous - the stack trace when setting breakpoints tells that they're directly called from UI.init().

Comment 19

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

So we're spending our time drawWindow()ing?  That doesn't seem to mesh with comment 15.

Comment 20

[Michael Yoshitaka Erlewine [:mitcho]]

Tim et al: should we add other dependencies for in-progress work here OR should we close this OR should we punt to the future but keep it open?

Comment 21

[Kevin Hanes]

bugspam. Moving b10 to b11

Comment 22

[Kevin Hanes]

bugspam. Removing b10

Comment 23

[Ian Gilman [:iangilman]]

I'm punting this. Tim, if it's still of use to you, we can keep it open (but punted); otherwise go ahead and close it... I don't think we need yet another perf meta bug.

Comment 24

[Tim Taubert [:ttaubert] (inactive)]

I'm totally with you.