initial group switch is very slow (nothing for seconds)

VERIFIED FIXED

Status

defect
P1
normal
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: dietrich, Assigned: seanedunn)

Tracking

({perf})

Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [tsnap])

Attachments

(1 attachment)

Reporter

Description

9 years ago
if i switch groups using the keyboard shortcut (ctrl/cmd + ~) without ever going into tabcandy, the first switch is extremely slow to happen.

sometimes it'll take up to 5 seconds.
blocking2.0: --- → ?
Note that the fix for this will likely be related to the fix for bug 595020.
Assignee: nobody → ian
Priority: -- → P2
Blocks: 597043
Keywords: perf

Updated

9 years ago
Blocks: 604213

Updated

9 years ago
Priority: P2 → P1
The time in question is the Panorama start-up time (as it needs to start up in order to get the group switch info). Looks like bug 588630 is going to make a big difference here. On my machine, without that patch, starting up Panorama with 100 tabs fully loaded takes 5 seconds, and 200 tabs takes 15 seconds. With the patch, 200 tabs takes 2 seconds.
Depends on: 588630
Beyond that, we could potentially load up the data and intelligence of Panorama without loading up the UI, since in this case the UI isn't needed. This will happen naturally as a part of bug 578512 (post ff4.0). Prior to that it's probably too radical of an architecture change. We should simply focus continuing to improve Panorama start time in general. 

Making this bug dependent on bug 588630; this can be closed when it lands, or marked as duplicate before.
Assignee: ian → seanedunn
I'm attaching the profiling test I used for this bug. Note that it has two "failures"; that's how I report how long it took to initialize Panorama (relevant to this bug) and show Panorama (just of interest, but not relevant to the bug). Change the 200 to some other number to load more or fewer tabs.
Reporter

Updated

9 years ago
Whiteboard: [tsnap]
Closing this now that bug 588630 has landed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Reporter

Comment 6

9 years ago
Posthumous blocking+.
Status: RESOLVED → REOPENED
blocking2.0: ? → final+
Resolution: FIXED → ---
Reporter

Comment 7

9 years ago
Ugh, flag munging.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Verified in recent nightly minefield build
Status: RESOLVED → VERIFIED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.