584445 - Idle CPU usage Minefield much higher than the FF 3.6.8 idle CPU usage (Mac OS X 10.6.4)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Onno Witvliet]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

On Mac X 10.6.4 the idle CPU usage for Firefox 3.6.8 is between 0.0 and 0.4%

With the latest Minefield build the idle CPU usage is between 4.1 and 5.2%

Reproducible: Always

Steps to Reproduce:
1. Create clean profile
2. Start Firefox / Minefield
3. Open about:blank in a tab
4. Close all other tabs
5. Observe the CPU usage of the firefox-bin process for some time with top or ps
Actual Results:  
The latest Minefield uses between 4 and 5% CPU while idle

Expected Results:  
Much lower idle CPU usage. CPU usage should be comparable with the usage of Firefox 3.6.8 

This regressed between the 2010-03-02 and the 2010-03-03 nightly builds:

http://hg.mozilla.org/mozilla-central/rev/ba77049941c3

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a3pre) Gecko/20100302 Minefield/3.7a3pre

Built from http://hg.mozilla.org/mozilla-central/rev/c99d708e789d

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a3pre) Gecko/20100303 Minefield/3.7a3pre

Comment 1

[Simon Howes]

I can reproduce this bug. Uses between 4-6% CPU according to Activity Monitor.

I can reproduce not just using about:blank, but with any web page, including only have one tab (or more) open with this bugzilla page.

Comment 2

[Onno Witvliet]

Attachment: idle CPU usage Firefox 3.6.8

Comment 3

[Onno Witvliet]

Attachment: idle CPU usage Minefield 02 March 2010 nightly

Comment 4

[Onno Witvliet]

Attachment: idle CPU usage Minefield 03 March 2010 nightly

Comment 5

[Onno Witvliet]

This is a major regression. 
This causes a laptop battery to drain more quickly (that is how I found this bug in the first place).

I hope this will be fixed for the release of Firefox 4.0

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

roc: can you look into this? I have a hard time believing it's SVG, but looks like it's a real idle time regression.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Onno, would you be willing to use nightly builds to try to narrow down when the problem appeared?

Comment 8

[Onno Witvliet]

This regressed between the 2010-03-02 and the 2010-03-03 nightly builds:

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-03-02+01%3A30%3A00&enddate=2010-03-03+16%3A00%3A00

Maybe this is caused by bug 501436

Comment 9

[Boris Zbarsky [:bzbarsky]]

Or conceivably bug 463695, since it made progressmeters on mac redraw every 33ms?  Or bug 542068, though that seems unlikely for about:blank...

Comment 10

[Markus Stange [:mstange]]

It's bug 463695. The setInterval timer is active even while the progressbar is invisible. In every iteration it notices that it's hidden and returns.
That's not much, but it's enough to create some garbage and trigger the garbage collector every once in a while, and going through the Gecko event loop isn't free, either.

It would be good to stop the timer once the progressbar detects that it's hidden, but then it would need to detect when it becomes visible again to restart the timer, and I'm not sure how it could do that.

Comment 11

[Boris Zbarsky [:bzbarsky]]

How do we hide the progressbar?  visibility:collapse, or display:none?  If not the latter, why not?

How quickly does the progressmeter need to respond to being unhidden?  Could it use a rarely-firing (2000ms? more?) timer to check, for example?

This seems like something we should just add core API for as needed, though.  Polling is ... suboptimal.

Comment 12

[Markus Stange [:mstange]]

(In reply to comment #11)
> How do we hide the progressbar?  visibility:collapse, or display:none?

visibility:collapse by setting collapsed="true" on the containing statusbarpanel.

> If not the latter, why not?

I don't know, but presumably showing it again would be more costly, and would affect the startup path? I could test that, though.

> How quickly does the progressmeter need to respond to being unhidden?  Could it
> use a rarely-firing (2000ms? more?) timer to check, for example?

Yeah, I suppose we could do that. The animation freezes all the time anyway, so people probably wouldn't notice if it didn't start animating instantly.

> This seems like something we should just add core API for as needed, though. 
> Polling is ... suboptimal.

The first approach I tried in bug 304147 actually added a Core API to nsITheme (WidgetNeedsPeriodicRedraw), so it only set a timer when the widget was in fact visible, but roc and Enn preferred the JavaScript binding solution.
Maybe it's time to revisit that approach using the refresh driver. Or maybe we should just do what you suggested until we can go the off-main-thread route (bug 546837).

Comment 13

[Boris Zbarsky [:bzbarsky]]

> showing it again would be more costly

It would, yes...  Not sure how much more, though.

> Maybe it's time to revisit that approach using the refresh driver.

Refresh driver seems like the wrong tool, since it would actually fire every 20ms.

What does changing the "step" attribute actually do?

Comment 14

[Markus Stange [:mstange]]

(In reply to comment #13)
> > Maybe it's time to revisit that approach using the refresh driver.
> 
> Refresh driver seems like the wrong tool, since it would actually fire every
> 20ms.

I don't mind having the timer fire more often while the progressbar is visible. As long as no timer fires at all while the progressbar is hidden, the problem this bug is about should be addressed, no?

> What does changing the "step" attribute actually do?

It triggers a redraw because we ask for it in nsNativeThemeCocoa::WidgetStateChanged.

Comment 15

[Markus Stange [:mstange]]

This will be fixed by bug 586216.

Comment 16

[Johnny Stenback (:jst)]

So, is this fixed? If not, please renominate for blocking2.0 if you think this needs more attention for Firefox 4.

Comment 17

[Onno Witvliet]

Attachment: idle CPU usage Minefield 12 December 2010 nightly

The regression has gone, the idle CPU usage is back to FF 3.6 values. 
I've tested this with the latest nightly:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101212 Firefox/4.0b8pre

Comment 18

[Wayne Mery (:wsmwk)]

WFM per comment 17