Closed Bug 770349 Opened 12 years ago Closed 11 years ago

Performance regression in 1k+ tab case

Categories

(Core :: General, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox16 - ---
firefox17 - ---
firefox18 - ---

People

(Reporter: bugzilla.mozilla.org, Assigned: mattwoodrow)

References

Details

(Keywords: perf, regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 Build ID: 20120629030530 Steps to reproduce: My profile has >1k tabs. Using today's nightly practically all UI actions (scrolling, typing text, switching tabs) are sluggish. kbrosnan suggested comparing to the 2012-06-29-03-05-30-mozilla-central build before the DLBI-landing. I'm generally getting GC pauses of 500+ ms and CC pauses of ~100ms but they seem to happen less frequently with the 29.06 build, which might explain at least part of the issue.
Depends on: dlbi
This could also be bug 758034, which landed in the same nightly. Mind bisecting with mozilla-inbound hourlies?
Actually, I have a backout patch handy for the stuff that landed in bug 758034 (for unrelated reasons). I just pushed it to Try. Once the builds finish, let me know if those builds work better. http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ryanvm@gmail.com-15c1b5e9380d
Component: Untriaged → General
Product: Firefox → Core
QA Contact: untriaged → general
(In reply to The 8472 from comment #0) > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 > Firefox/16.0 > Build ID: 20120629030530 > > Steps to reproduce: > > My profile has >1k tabs. Using today's nightly practically all UI actions > (scrolling, typing text, switching tabs) are sluggish. > I switched from 2012-06-24 build to 07-03 build. I agree, UI is sluggish. 361 tabs. somewhat nominal GC and CC numbers. context menus also seem somewhat slow OTOH, I'm not currently seeing windows go "Not Responding"
Keywords: perf, regression
(In reply to Wayne Mery (:wsmwk) from comment #3) > (In reply to The 8472 from comment #0) > > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 > > Firefox/16.0 > > Build ID: 20120629030530 > > > > Steps to reproduce: > > > > My profile has >1k tabs. Using today's nightly practically all UI actions > > (scrolling, typing text, switching tabs) are sluggish. > > > > I switched from 2012-06-24 build to 07-03 build. I agree, UI is sluggish. > 361 tabs. somewhat nominal GC and CC numbers. > > context menus also seem somewhat slow > > OTOH, I'm not currently seeing windows go "Not Responding" Did you try the build in comment 2?
(In reply to Ryan VanderMeulen from comment #2) > let me know if those builds work better. Significantly more sluggish than the 2012-06-29 build And I can't tell the difference to the current nightly, if there is any.
Since the backout of DLBI everything is fast again, so it was definitely that.
Blocks: dlbi
No longer depends on: dlbi
Not tracking for 16 since bug 539356 is backed out from 16.
leaving it nominated though, so we have it on our radar depending on the status of bug 539356
At this point, DLBI (bug 539356) does not appear as if it'll land for 16. Please set the tracking-firefox16 flag back to ? if you're able to reproduce on Aurora.
Is this regression being seen on Aurora 17? Flagging qawanted and verifyme to see if this is still present so we can make a call on continuing to track.
Keywords: qawanted, verifyme
@The8472, can you please try the latest Firefox 17.0a2 Aurora build from https://aurora.mozilla.org using your profile? We need your help in determining if this is reproducible with the latest Aurora. Thank you
1000+ tabs is not something we can easily test, certainly not manually. In my opinion this is an edgecase which we should rely on the reporter to verify (as asked in comment 11). Dropping QAWANTED from this bug.
Keywords: qawanted, verifyme
Assignee: nobody → matt.woodrow
The 8472, if you enable the pref nglayout.debug.paint_flashing do you see unnecessary painting (indicated by flashing)?
(In reply to The 8472 from comment #0) > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 > Firefox/16.0 > Build ID: 20120629030530 > > Steps to reproduce: > > My profile has >1k tabs. Using today's nightly practically all UI actions > (scrolling, typing text, switching tabs) are sluggish. > > kbrosnan suggested comparing to the 2012-06-29-03-05-30-mozilla-central > build before the DLBI-landing. > > I'm generally getting GC pauses of 500+ ms and CC pauses of ~100ms but they > seem to happen less frequently with the 29.06 build, which might explain at > least part of the issue. Hi The 8472 , Can you please help us retest the reported issue as per comment 13 ? Will not be tracking the bug for FF18 based on your results as it seems difficult for the QA to test this in particular
At this time, considering this is hard to test/reproduce and something which may have improved after lots of DLBI patches landing in 18,untracking this for FF18. Please set tracking-firefox18 to ? if the perf regression is reproducible on Aurora .
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #11) > @The8472, can you please try the latest Firefox 17.0a2 Aurora build from > https://aurora.mozilla.org using your profile? We need your help in > determining if this is reproducible with the latest Aurora. Thank you
Flags: needinfo?(bugzilla.mozilla.org)
Whiteboard: [closeme 2013-11-25]
Resolved per whiteboard PS: but I know that therube have a couple of such test cases :D
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(bugzilla.mozilla.org)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2013-11-25]
You need to log in before you can comment on or make changes to this bug.