1052142 - [Clock] About 50% CPU load on Flame device when using the stopwatch

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Clock, defect, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Gaia      597975839c04e0198eb98c2c77474f057b5531e7
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ddeead927143
BuildID   20140805000238
Version   32.0
ro.build.version.incremental=110
ro.build.date=Fri Jun 27 15:57:58 CST 2014
B1TC00011230

Whenever I'm using the stopwatch on my Flame device the CPU load climbs up to more than 50%. That's way too much given that it only displays the time elapsed. But maybe we update it too often. See also all this flickering. 

Steps:
1. Enable developer options
2. Run 'adb shell top -m 5'
3. Open the alarm app and change to the stopwatch
4. Lets wait until the cpu load has been settled
5. Start the stopwatch
6. Lets wait until the cpu load has been settled

In case of step 4 I see a load of about 6% of the b2g process for most of the apps. But for step 6 it is at about 18%, which doesn't go down even waiting a longer time. Beside this also the plugin-container process is using about 34% which is 30% more than normal

Stopwatch not running:

  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
  317  0   6% S    45 196608K  89148K     root     /system/b2g/b2g
 1826  0   4% S    12  74972K  28560K     u0_a1826 /system/b2g/plugin-container

Stopwatch running:

  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
 1826  0  34% S    12  75164K  28636K     u0_a1826 /system/b2g/plugin-container
  317  1  18% S    45 196608K  89148K     root     /system/b2g/b2g

So keeping the keyboard open even in idle mode will drain your battery faster.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

This also needs a CPU profile.

Comment 2

[Eric Rahm [:erahm]]

I'll see if I can get more details.

Comment 3

[Eric Rahm [:erahm]]

I was able to reproduce this behavior. I profiled a 2.0 non-debug build with MOZ_PROFILING=1 and the following command:

  ./profile.sh start -f stackwalk,js -p b2g && ./profile.sh start -f stackwalk,js -p Clock

The report is available in Cleopatra:
  https://people.mozilla.org/~bgirard/cleopatra/#report=a1acd1fb8cdf1d2d7d2eeb98d300226fc26fb614

The best I can tell most of that time is spent painting, indicating this is probably a graphics related issue.

Comment 4

[Eric Rahm [:erahm]]

A little more digging isolates the issue to the point where we update the actual time field [1].

I did a few tests:
  1) disable the line, cpu usage goes away
  2) modify durationMS to return just seconds precision, cpu usage stays the same
  3) do 2) _and_ only update the field if the time changed, cpu usage drops drastically
  4) Always set to '00:00.00', cpu usage stays the same

So we can see that _any_ update to the field is causing high cpu usage (we're using requestAnimationFrame to update, so this is pretty frequent).

[1] https://github.com/mozilla-b2g/gaia/blob/a40e5d7ad238c03945309e45d0ccc65c815c85d5/apps/clock/js/panels/stopwatch/main.js#L79

Comment 5

[Jon Hylands [:jhylands]]

See bug 947617 for something that sounds identical that I fixed for the clock app.

The way to check is turn on "Flash repainted area" option in the developer menu - you'll see how often and how much of the screen is being updated. We were able to dramatically reduce power and cpu consumption in the clock app by forcing the gpu to do the screen update.

Comment 6

[BMO Automation]

Firefox OS is not being worked on