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: 188.8.131.52-prerelease master Platform version: 36.0a1 Build Identifier: 20141128194540 Git commit info: 2014-11-28 13:27:14 7d3f9852
Profile taken during the scenario execution: http://people.mozilla.org/~bgirard/cleopatra/#report=2de21c91db0969d485e0e1b4280f4169a38b6478
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.
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.
I mean the state when user pressed LID button and screen has turned off.
(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?
How many items do you ask in that DataStore::get() ? Just 1 ore more than 1?
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.
Don't know why you changed the Component :) Maybe you wanted Gaia::System?
Let's consider blocking for this performance (and likely battery !) improvement.
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!
Can QA reproduce?
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.
I sent the mem dump to :kgrandon. If anyone wish to get access to the dump please contact with him.
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
(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.
Back to SMS based on comment 14.
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.
Mass closing of Gaia::SMS bugs. End of an era :(
Mass closing of Gaia::SMS bugs. End of an era :(