770349 - Performance regression in 1k+ tab case

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[The 8472]

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.

Comment 1

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

This could also be bug 758034, which landed in the same nightly. Mind bisecting with mozilla-inbound hourlies?

Comment 2

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

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/[e-mail]-15c1b5e9380d

Comment 3

[Wayne Mery (:wsmwk)]

(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"

Comment 4

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

(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?

Comment 5

[The 8472]

(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.

Comment 6

[The 8472]

Since the backout of DLBI everything is fast again, so it was definitely that.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Not tracking for 16 since bug 539356 is backed out from 16.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

leaving it nominated though, so we have it on our radar depending on the status of bug 539356

Comment 9

[Alex Keybl [:akeybl]]

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.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 11

[u279076]

@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

Comment 12

[u279076]

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.

Comment 13

[Timothy Nikkel (:tnikkel)]

The 8472, if you enable the pref nglayout.debug.paint_flashing do you see unnecessary painting (indicated by flashing)?

Comment 14

[bhavana bajaj [:bajaj]]

(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

Comment 15

[bhavana bajaj [:bajaj]]

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 .

Comment 16

[Wayne Mery (:wsmwk)]

(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

Comment 17

[Phoenix]

Resolved per whiteboard
PS: but I know that therube have a couple of such test cases :D