Closed Bug 812987 Opened 12 years ago Closed 12 years ago

[SMS] CPU usage is high when message app is opened

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Platform:
x86
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-basecamp:+)

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +

People

(Reporter: khu, Unassigned)

References

Details

Attachments

(1 file)

Profiling data
970.79 KB, application/zip
Details 
Step to reproduce: 
1. Open message app. 
2. Check CPU usage with top command. 

Even there has no messages and I do nothing(no operation is performed), the total CPU usage is around 40% or higher: 

  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
  371  0  27% S    11  70180K  21976K  fg app_0    /system/b2g/plugin-container
  110  0  17% S    37 210620K  64828K  fg root     /system/b2g/b2g

It never goes down, unless the screen goes off, or close message app. I used nightly build(unagi_2012-11-18.zip).
Nominate as bb?. We can discuss if we should flag this as bb+.
blocking-basecamp: --- → ?
By the way, it happened on both Unagi and Otoro.
Does the cpu drop down when you switch apps?  Wondering what the user impact here is so that we can decide if this bug is blocking or not.
Flags: needinfo?(khu)
If the app goes to background, the CPU will go down. Just wondering why the CPU is high, because it looks like the app should do nothing, especially when there has no data in the app.
Flags: needinfo?(khu)
We need some profile.sh love here.
Kevin, can you have someone in Taipei grab the profile?
Flags: needinfo?(khu)
Attached file Profiling data — 
Hi, I tried to do the profiling twice. Please refer to the attachment for the profiling data. Thank you.
Flags: needinfo?(khu)
Who can interpret the profiling data and see what needs to be fixed here?  David, who is the best owner in your opinion?
blocking-basecamp: ? → +
Flags: needinfo?(dscravaglieri)
Here's what the SMS app is doing

http://people.mozilla.com/~bgirard/cleopatra/#report=5a606dae45016e5ef65870a0bfc2196bdf5e4c8c

There's no JS in the samples, just gecko repainting.  It looks like there's an animation that's been left running accidentally.
Component: General → Gaia::SMS
QA Contact: mbarone976
The same thing happens in the Contacts app, btw. I thought animations on opacity:0 divs shouldn't be painted? Should we open a platform bug with a small test case?
Kevin the spinner animation has been removed in bug 816637.

Can you check again with the latest gaia build and see if that helps?
(In reply to Tim Taubert [:ttaubert] from comment #10)
> The same thing happens in the Contacts app, btw. I thought animations on
> opacity:0 divs shouldn't be painted? Should we open a platform bug with a
> small test case?

You mean animated images or CSS animations?

Either way, let's file a followup to fix contacts too.
Flags: needinfo?(dscravaglieri)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> (In reply to Tim Taubert [:ttaubert] from comment #10)
> > The same thing happens in the Contacts app, btw. I thought animations on
> > opacity:0 divs shouldn't be painted? Should we open a platform bug with a
> > small test case?
> 
> You mean animated images or CSS animations?

The contacts app has a loading overlay infinitely animating/moving an element's background-position property.

> Either way, let's file a followup to fix contacts too.

Will do. I'll open a platform bug with a test case as well.
(In reply to Tim Taubert [:ttaubert] from comment #13)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> > (In reply to Tim Taubert [:ttaubert] from comment #10)
> > > The same thing happens in the Contacts app, btw. I thought animations on
> > > opacity:0 divs shouldn't be painted? Should we open a platform bug with a
> > > small test case?
> > 
> > You mean animated images or CSS animations?
> 
> The contacts app has a loading overlay infinitely animating/moving an
> element's background-position property.

Yeah, in general gecko doesn't know a priori when sampling a value of an animation will result in it changing rendering or not.  So it has to keep them running.  Even elements with opacity:0 can affect rendering (cause overflow which shows scroll bars, for example).
Hi, Vivien, I flashed unagi_2012-11-29.zip and the issue is still there...please refer to the following result from top command: 

User 52%, System 9%, IOW 11%, IRQ 0%
User 166 + Nice 0 + Sys 30 + Idle 85 + IOW 35 + IRQ 0 + SIRQ 0 = 316

  PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
  410   410  0  44% R  74908K  31252K  fg app_0    Messages        /system/b2g/plugin-container
  109   240  0   8% S 198188K  66928K  fg root     Compositor      /system/b2g/b2g
  109   109  0   2% S 198188K  66928K  fg root     b2g             /system/b2g/b2g
  548   548  0   2% R   1096K    456K  fg root     top             top
  410   430  0   1% S  74908K  31252K  fg app_0    Timer           /system/b2g/plugin-container
  410   411  0   0% S  74908K  31252K  fg app_0    Chrome_ChildThr /system/b2g/plugin-container
  109   243  0   0% S 198188K  66928K  fg root     Timer           /system/b2g/b2g
  109   394  0   0% S 198188K  66928K  fg root     GL updater      /system/b2g/b2g
  109   232  0   0% S 198188K  66928K  fg root     Gecko_IOThread  /system/b2g/b2g
  109   242  0   0% D 198188K  66928K  fg root     b2g             /system/b2g/b2g
(In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> Yeah, in general gecko doesn't know a priori when sampling a value of an
> animation will result in it changing rendering or not.  So it has to keep
> them running.  Even elements with opacity:0 can affect rendering (cause
> overflow which shows scroll bars, for example).

Oh, that totally makes sense. Thank you for clarifying. This may be a little too much for such few use cases but maybe we could just suspend animations that pretty sure won't affect things like overflow, etc. (animating backgrounds, colors and stuff).
(In reply to Chris Jones [:cjones] [:warhammer] from comment #12)
> Either way, let's file a followup to fix contacts too.

Filed bug 816895.
I still see the SMS app using a consistent 37-38% CPU in a build that includes bug 816637.
Strange, it's 0% CPU usage here with all of the test contacts imported.
m( I'll see myself out and try with the SMS app again.
SMS app is idling at 0-1% in thread and edit view for me.
Retested with a fresh build and it's fixed.  Not sure what happened ...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: