Closed Bug 962211 Opened 11 years ago Closed 9 years ago

Australis uses too many resources and has high energy usage

Categories

(Firefox :: Untriaged, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: wycats, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36 Steps to reproduce: 1. Use Australis for a few hours, accumulating about 15 tabs, with the Flashblock and Pocket extensions installed. 2. Use Aurora for a few hours starting with the same set of tabs and retaining around 15 tabs throughout. 3. Use Chrome for over the course of a few days, accumulating a similar number of tabs with many more extensions installed. Actual results: Firefox Nightly uses a surprising amount of memory, and is actively the top result under the Mavericks "Energy" pane in the activity monitor. Aurora use significantly less memory and energy. Chrome is a little harder to examine because it has many "helper" processes, but it appears to use less memory and definitely uses less energy.
Incidentally, "TweetDeck" listed in the Activity Monitor image is a Firefox App, and uses surprisingly many resources.
If you want to see if this is actually from the Australis redesign or just other changes on Nightly, you should compare Nightly with Holly instead. Holly is Nightly minus the Australis changes. You can download it from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-holly/
Blocks: 962671
Roberto, can you try reproducing this bug report and also check if this is indeed a regression?
Flags: needinfo?(rvitillo)
Assignee: nobody → rvitillo
Flags: needinfo?(rvitillo)
I am downloading Holly as we speak.
I ran Holly and Australis for about 4 hours using the same Sync account and 10 open tabs, including Gmail and IRCCloud. According to the Activity Monitor, Holly used 29 minutes of CPU and Australis used 34 minutes of CPU. They each use around 600MB of RAM. At the end of the run, Holly is chewing about 15% CPU in idle, while Nightly is using between 20 and 25% CPU. I also see more spikes of Nightly jumping up above 50%, while Holly seems to be more consistent around 15%. This is all anecdotal, and based on the specific tabs that I had open, but I tried to eliminate as many variables as possible in the run.
I run some quick tests and I wasn't able yet to reproduce the bug. It appears that in your case Chrome consumes the least amount of energy. A very simple test with just 3 tabs open (Gmail, IRCCloud & CNN) yield a completely different result on my machine after just one hour: Chrome had an energy impact nearly twice as high as Nightly. I used a clean profile for both FF and Chrome though. I also collected some energy samples (30min intervals) for 20 GMails tabs to compare Nightly to Release and a t-test of the average energy impact failed to reject the null hypothesis. It would be great if you could provide me the following information: 1) The URLs of all the websites you had loaded in your browser 2) The number of channels you were connected to in IRCCloud and the average activity on that channels 3) When you compared Nightly to Holly, were both browsers running concurrently? 4) How does your profile look like on FF? Which other plugins and add-ons do you have installed apart from Flashblock and Pocket? 5) You saw a see a clear difference between the CPU usage of Holly (20-25%) and Nightly (15%). Was that difference visible also earlier on or did you have to wait hours to notice it?
Ok, I have left both running over night. The results: Nightly: - Idle CPU usage: 50-80% - Total CPU used: 2 hours, 38 minutes Holly: - Idle CPU usage: 10-20% - Total CPU used: 1 hour, 19 minutes
URLs: - https://mail.google.com - https://irccloud.com - http://news.ycombinator.com - http://dailykos.com - http://talkingpointsmemo.com - http://yehudakatz.com - http://wonkblog.com - http://krugman.blogs.nytimes.com/ For what it's worth, after running overnight, both Holly and Nightly have a non-responsive script error in gmail and the entire browser is locked up.
In IRCCloud, I have four IRC servers open: - Freenode - Mozilla - W3C - A private IRC server with low traffic I have 38 total channels open and another 10 private messages open. Activity levels can be pretty high (for example, I am logged into #whatwg and #emberjs). Both browsers were running at the same time. Those are the only plugins I had installed. The difference was not visible at first but became larger as time passed (and was obvious at 4 hours).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yehuda, it could also be that your firefox profile is causing additional problems that we can't reproduce. Can you try firefox with the same pages, via a separate profile? Launch it with something like mkdir foo;firefox -no-remote -profile foo/ See if you still get the same problems with this newly-created profile
I left Nightly, Holly and Release running over night with a fresh profile on the same URLs and I got the following result: Nightly: - Idle CPU usage: 15-20% - Total CPU used: 1 hour, 07 minutes Holly: - Idle CPU usage: 15-20% - Total CPU used: 1 hour, 10 minutes Release: - Idle CPU usage: 15-20% - Total CPU used: 1 hour, 16 minutes
Did you log into gmail?
Yes, I was logged into gmail and irccloud.
Related result: When I did the overnight test of Nightly and Holly, I woke up to both of them with an unresponsive script warning in Gmail. I noticed it again this morning on my regular Nightly install so I figured I'd mention it. I'll try with Aurora tonight.
Hmmm... I am quite baffled. I do get a lot of email. Perhaps there is something pathological about my Gmail account that is triggering some pathological behavior in Firefox?
Were you logged into Hangouts? Do you get messages on Hangouts? I will try reproducing with G+ with Hangouts open instead of Gmail.
Possibly, I didn't have any unresponsive script warning. It would be great if you try with a new profile as Taras suggested.
No, I wasn't logged into Hangouts.
When I got into the office this morning, I saw Nightly hung again so I was able to grab the script that was hanging. I can confirm that it's Hangouts: Script: https://talkgadget.google.com/_/scs/talk-static/_/js/k=wcs.wbl.en.D_ZsvMeilFQ.O/m=b,r/am=Cp9glyBc-AIYQwMCHA/rt=j/d=1/rs=AItRSTNa-YEN3sIp2DidKJZXokFvuj4Gjg:16 Hangouts is a hog in pretty much all browsers, but it seems that something may be especially bad in the new UI?
Also, before I ran the overnight experiment, I created two fresh profiles.
(In reply to Yehuda Katz from comment #19) > When I got into the office this morning, I saw Nightly hung again so I was > able to grab the script that was hanging. I can confirm that it's Hangouts: > > Script: > https://talkgadget.google.com/_/scs/talk-static/_/js/k=wcs.wbl.en. > D_ZsvMeilFQ.O/m=b,r/am=Cp9glyBc-AIYQwMCHA/rt=j/d=1/rs=AItRSTNa- > YEN3sIp2DidKJZXokFvuj4Gjg:16 404 not found. Is there any way you could attach the script to this bug?
Attached file hangoutsScript.txt
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #21) > 404 not found. Is there any way you could attach the script to this bug? Done
I wasn't able to reproduce the bug when logged into Hangouts.
(In reply to Yehuda Katz from comment #19) > When I got into the office this morning, I saw Nightly hung again so I was > able to grab the script that was hanging. I can confirm that it's Hangouts: > > Script: > https://talkgadget.google.com/ I've seen this too. It's been happening intermittently over the past week or so. I think I've only seen it in Nightly (I run both Nightly and Release). Hard to isolate, but it's possible this could be a Google JS bug.
I think we've diverged from comment 0 significantly here, but the talkwidget issue merits its own investigation. I filed bug 964560 for that.
Does the Gecko profiler have a mechanism for attributing performance cost to particular pages? If not... it's something I've been thinking for quite a while (since summer 2010) that we should work on. (Also, have all the comparisons been done on similar Firefox profiles?)
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #26) > Does the Gecko profiler have a mechanism for attributing performance cost to > particular pages? If not... it's something I've been thinking for quite a > while (since summer 2010) that we should work on. > > (Also, have all the comparisons been done on similar Firefox profiles?) No, adding the support for it is quite trivial but instrumenting the code base for this is quite hard. We would need something like: EnterPageContext("Blah") The quality of these instrumentation would dictate how well this feature works. Complex cases is where you enter a page context but then execute something else meanwhile (spinning an event loop, crossing a component etc). Bug would cause under/over-reporting. I'm happy to commit to adding the backend support for it if someone thinks they can annotate the code base.
Assignee: rvitillo → nobody
Hi Yehuda, I talk with Roberto and we were asking if you still see this behaviour on the latest Firefox version? Thank you for your time.
Flags: needinfo?(wycats)
Hi, Marking this as Resolved: Incomplete due to the lack of response from the reporter. Reporter, please feel free to reopen it if you are still having this issue on the latest Firefox version.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(wycats)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: