Open Bug 1190719 Opened 9 years ago Updated 1 year ago

High power usage on 8tracks.com

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

People

(Reporter: n.nethercote, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: power, Whiteboard: [Power:P2])

Attachments

(1 file)

graph of results
99.74 KB, image/jpeg
Details
Attached image graph of results — 
The following blog post identified Firefox as having much higher power consumption than Safari or Chrome on 8tracks.com:

http://blog.getbatterybox.com/which-browser-is-the-most-energy-efficient-chrome-vs-safari-vs-firefox/

The attached graph shows the results.

Firefox was also the worst on Soundcloud, though the difference was much smaller.
I can confirm this. Using the unitless "Energy Impact" measurement in the OS X
Activity Monitor, I got the following measurements while streaming music at
8tracks.com/stephrmo/movin-on:

> Nightly (e10s): ~80--90
> - Nightly: ~22
> - Nightly Web Content: ~55
> - Nightly Plugin Content: ~8
> 
> Nightly (non-e10s): ~65--75
> - Nightly: ~65
> - Nightly Plugin Content: ~9
> 
> Chrome: ~75--82
> - Chrome: ~13
> - Chrome Helper: ~35
> - Chrome Helper: ~25
> - Chrome Helper: ~1
> 
> Safari: ~21--22
> - Safari: < 1
> - Safari Web Content: ~10
> - Flash Player: ~11

In each case, the measurement on the first line is the combined measurement for
all the processes, and then the lines below that give the per-process
breakdown.

I also measured power usage with |powermetrics|:

> Nightly (e10s): 16.6W
> Chrome:         12.9W
> Safari:          5.3W

These results all roughly match the blog post results -- Firefox is worst, then
Chrome, then Safari, and the differences are large.
When I'm playing a song on 8-tracks, and the tab is in the foreground, the "energy impact" in the OS X Activity Monitor for the content process is about 60. When the tab is in the background, the energy impact for the content process drops to about 12. (This is with all my other random tabs open, too.) That seems suspicious.
What if Flash is disabled?
The CPU usage also doubles or triples when the tab is in the foreground.

Using the OSX profiler, something like 27% of CPU time is spent under PresShell::Paint. Another 22% is spent inside nsGlobalWindow::RunTimeout(), almost entirely in MessageChannel::WaitForSyncNotify(). Then there's 36% under this mac_msg_trap (which is what 96% of the time is spent on when bugzilla is in the foregrounds, so maybe this is an idle loop).
(In reply to Milan Sreckovic [:milan] from comment #3)
> What if Flash is disabled?

With Flash blocked, the usage is about the same in the foreground as the background. (My numbers for the above do not include the Flash process, which didn't seem too bad.)

I used the paint flashing devtool thing, and the only obvious painting that I saw was that it was frequently painting the progress bar thing that shows how far into the song it is.
When Flash is enabled, but the music is paused and the tab is in the foreground, then the energy impact is about the same as when the tab is in the background.
It looks like mostly layout stuff, so I'm going to move it there for now.
Component: General → Layout
Product: Firefox → Core
I looked at this a bit. The width is being transition on the player_progress_bar_meter. It looks like this is causing us to attempt to paint at 60fps. Safari seems to not be hurt as badly by this. I'm exactly sure why.
Safari does seem to be painting the player_progress_bar_meter at a high rate, perhaps they're just handling it much better.
Chrome team seems to think safari has a better optimized graphics stack that avoids some issues on mac os x.  See bug 1190409.
(In reply to Ben Kelly [:bkelly] from comment #12)
> Chrome team seems to think safari has a better optimized graphics stack that
> avoids some issues on mac os x.  See bug 1190409.

We're using a lot more cpu on this page than Safari so I don't think we're being limited by our interaction with the OS graphics stack.
Looking closer it seems like Safari is not trying to paint the page at 60fps instead only at 45-50fps. I don't know why. Still painting at a lower rate should make a noticeable different in battery.

Chrome seems to paint at about 55fps. We do a solid 60fps.
Whiteboard: [Power]
No longer blocks: 1190718
(In reply to Jeff Muizelaar [:jrmuizel] from comment #15)
> I've created a standalone tests case here:

For me, that doesn't play the music and the power consumption for Firefox is only ~6 Watts rather than the 20+ Watts I get on the original site.
Here are some updated, more detailed measurements of
http://8tracks.com/stephrmro/movin-on.

Firefox Nightly (with e10s):

>     total W = _pkg_ (cores + _gpu_ + other) + _ram_ W
> #01 22.66 W = 19.07 ( 3.35 +  5.71 + 10.01) +  3.59 W
> 
> 1 sample taken over a period of 30.000 seconds
> 
> Name                               ID     CPU ms/s  User%  Deadlines (<2 ms, 2-5 ms)  Wakeups (Intr, Pkg idle)  GPU ms/s
> com.apple.Terminal                 293    878.15                                      255.74  98.65             443.00
>   firefox                          83911  194.63    72.49  0.03    0.93               74.99   48.27             442.98
>   plugin-container                 83913  670.10    95.20  11.79   11.03              29.85   15.92             0.00
>   plugin-container                 83916  35.71     74.81  2.23    0.00               150.35  34.28             0.00
>   Terminal                         694    5.99      88.53  0.00    0.00               0.47    0.13              0.00

Safari:

>     total W = _pkg_ (cores + _gpu_ + other) + _ram_ W
> #01  7.09 W =  5.27 ( 0.38 +  0.20 +  4.69) +  1.82 W
> 
> 1 sample taken over a period of 30.000 seconds
> 
> Name                               ID     CPU ms/s  User%  Deadlines (<2 ms, 2-5 ms)  Wakeups (Intr, Pkg idle)  GPU ms/s
> com.apple.Safari                   698    116.23                                      56.24   49.28             7.70    
>   com.apple.WebKit.WebContent      83966  110.16    84.61  1.40    0.00               54.58   48.08             7.70
>   Safari                           83962  8.09      53.26  0.00    0.00               0.90    0.63              0.00    
>   com.apple.WebKit.Networking      83965  2.38      54.97  0.00    0.00               0.50    0.43              0.00    
>   com.apple.Safari.SearchHelper    83971  0.06      44.11  0.00    0.00               0.23    0.10              0.00    
> com.apple.WebKit.Plugin.64         699    35.47                                       147.31  107.72            0.00    
>   com.apple.WebKit.Plugin.64       83970  35.49     71.65  1.93    0.00               147.31  107.73            0.00    
> com.apple.Terminal                 293    5.38                                        0.53    0.43              0.00    
>   Terminal                         694    5.09      92.06  0.00    0.00               0.47    0.37              0.00    

Chrome:

>     total W = _pkg_ (cores + _gpu_ + other) + _ram_ W
> #01  5.84 W =  4.31 ( 0.51 +  0.15 +  3.66) +  1.52 W
> 
> 1 sample taken over a period of 30.000 seconds
> 
> Name                               ID     CPU ms/s  User%  Deadlines (<2 ms, 2-5 ms)  Wakeups (Intr, Pkg idle)  GPU ms/s
> com.google.Chrome                  700    257.23                                      205.28  177.76            5.14
>   Google Chrome Helper             83994  214.61    82.82  0.00    0.00               176.47  156.28            0.00
>   Google Chrome                    83982  34.20     79.09  0.10    0.20               22.69   16.53             0.00
>   Google Chrome Helper             83988  6.64      58.94  0.00    0.00               6.13    4.96              5.14
> com.apple.Terminal                 293    5.98                                        0.50    0.33              0.00
>   Terminal                         694    5.69      89.58  0.00    0.00               0.43    0.27              0.00

GPU usage is clearly a problem for Firefox.

I don't know why Safari and Chrome have swapped positions in terms of which is best.
(In reply to Nicholas Nethercote [:njn] from comment #16)
> For me, that doesn't play the music and the power consumption for Firefox is
> only ~6 Watts rather than the 20+ Watts I get on the original site.

When I looked at this, it wasn't the music playing that seemed to be the problem, it was drawing the progress bar.
> When I looked at this, it wasn't the music playing that seemed to be the
> problem, it was drawing the progress bar.

Maybe it's not the music that's the reason, but the measurements show the local copy is not a good substitute for the original.
Depends on: 1204549
Whiteboard: [Power] → [Power:P2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: