1106898 - High CPU load when showing notification about incoming SMS

Status: RESOLVED WONTFIX

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

Description

[mac]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1. Lock the device - screen is off.
2. Send SMS to the device.


Actual results:

About 57% CPU load when screen turns on and notification appears on the top of the screen.


Expected results:

It can't consume so much of CPU power just to show static notification about incoming SMS message.

Tested on:

Alcatel One Touch Fire production (got from T-mobile Poland)
B2G version: 2.2.0.0-prerelease master
Platform version: 36.0a1
Build Identifier: 20141128194540
Git commit info: 2014-11-28 13:27:14 7d3f9852

Comment 1

[mac]

Profile taken during the scenario execution:

http://people.mozilla.org/~bgirard/cleopatra/#report=2de21c91db0969d485e0e1b4280f4169a38b6478

Comment 2

[Greg Weng [:snowmantw][:gweng][:λ]]

Could you clarify that "lock" the device means with LockScreen (it shows after pressing power button again), or without it (just black out)? If both cases the performance downgrade happens, this is a bug not of LockScreen component. If you only test with one case you may try the other one.

Comment 3

[Greg Weng [:snowmantw][:gweng][:λ]]

And from the profile I see that it spends 29% time on "DataStoreDB.prototype.txn", and 25.2% on "AsyncConnectionHelper". None of these looks related to LockScreen.

Comment 4

[mac]

I mean the state when user pressed LID button and screen has turned off.

Comment 5

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to mac from comment #4)
> I mean the state when user pressed LID button and screen has turned off.

Yeah, not a lockscreen issue.


Baku, looking at the profile I think this has something to do with the Datastore API and possibly it's underlying use of IndexedDB. Can you take a look at the profile and help us confirm?

Comment 6

[Andrea Marchesini [:baku]]

How many items do you ask in that DataStore::get() ? Just 1 ore more than 1?

Comment 7

[Michael Henretty [:mikehenrty][:mhenretty]]

It looks like the DataStore transaction is coming from editing the places database in the system app. I spoke with :kgrandon on IRC about it, and he says he can help take a look.

Comment 8

[Julien Wajsberg [:julienw]]

Don't know why you changed the Component :) Maybe you wanted Gaia::System?

Comment 9

[Julien Wajsberg [:julienw]]

Let's consider blocking for this performance (and likely battery !) improvement.

Comment 10

[Kevin Grandon :kgrandon]

I was unable to get into a state where places was making datastore requests during the notificaiton. I think it might be a red herring, and the real cause might be something else. To proceed I think we're going to need additional information.

Mac - could you provide us with a memory dump using get_about_memory.py? This should help us narrow down what to look into next. Validating the repro steps and profile, or providing a video might also help. Thanks!

Comment 11

[Gregor Wagner [:gwagner]]

Can QA reproduce?

Comment 12

[Julien Wajsberg [:julienw]]

I wonder if this could come from the SMS application itself? Because in background we're actually rendering a full SMS application including rendering conversations.

This is mostly history from past days, but this is also quite nice because when the user taps the notification, the SMS application is actually ready. UX would need to tell us if this is something we'd want or if we'd rather close the application after sending the notification.

Comment 13

[mac]

I sent the mem dump to :kgrandon. If anyone wish to get access to the dump please contact with him.

Comment 14

[Brogan Zumwalt [Inactive]]

Seeing this issue occur on Flame 2.1, 2.2, and 3.0

Using the command "adb shell top -m 5" to test, observed CPU spike when message is received while screen is off appears nearly the same as when receiving SMS while on Homescreen. Tested empty messages app with no previous SMS's as well as SMS inbox filled using make-reference workload. Only seeing massive 50%+ spike during the first few tests, continuing to test on device sees spikes gradually drop off to around no more than 20%.

Device: Flame 2.1
BuildID: 20150113001255
Gaia: 836e6d74cb8b7016df555f85445893b3ff9aac12
Gecko: 074f79a929d2
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.2
BuildID: 20150113002520
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: df130262b09e
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 3.0 Master
BuildID: 20150113010202
Gaia: 9946a490a9264b42e65385d703b28fa055ab2d42
Gecko: 3d846527576f
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Comment 15

[Julien Wajsberg [:julienw]]

(In reply to Brogan Zumwalt [:BroganZ] from comment #14)
> Seeing this issue occur on Flame 2.1, 2.2, and 3.0
> 
> Using the command "adb shell top -m 5" to test, observed CPU spike when
> message is received while screen is off appears nearly the same as when
> receiving SMS while on Homescreen. Tested empty messages app with no
> previous SMS's as well as SMS inbox filled using make-reference workload.
> Only seeing massive 50%+ spike during the first few tests, continuing to
> test on device sees spikes gradually drop off to around no more than 20%.

Yeah, because if the SMS app is already launched in background, we don't launch it again obviously.

I think that with a reference workload, you'll have the "50%" spike during a longer time.

Comment 16

[Gregor Wagner [:gwagner]]

Back to SMS based on comment 14.

Comment 17

[Julien Wajsberg [:julienw]]

Just want to note to triagers: this is really a UX question, see comment 12. I'm fine with changing the behavior. However maybe it should not be a blocker because this is how it works since v1.0.

Comment 18

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: non-blocker. (Refer to comment 12 and comment 17).

Comment 19

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 20

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(