Closed Bug 806592 Opened 9 years ago Closed 8 years ago

[meta] Improve SMS app performance


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

Gonk (Firefox OS)
Not set


(Not tracked)



(Reporter: cjones, Unassigned)



(Keywords: perf, Whiteboard: UX-P2)

It takes about 10 seconds for the SMS app to load on my unagi after I've been dogfooding for about a week.

I'm not a very heavy SMS-er, so I'm guessing I have at most 100 stored messages by now.
blocking-basecamp: --- → ?
We have to send out some general guidance on this. I am seeing tons of heavy startup code in apps. The rule should be to exactly do nothing during startup.
Blocking+: This needs to be fixed sooner rather than later.
blocking-basecamp: ? → +
Priority: -- → P2
Assignee: nobody → fabrice
Note, the SMS app currently loads an omgbigfatslow JS library, which I think dings startup by 3 or 4 seconds.  We have a separate fix for that in hand.  The work here is on killing the extra 6-7s.
After talking with [:philikon] and [:ferjm] we have realized that there are key points for increasing the performance. What do you think about opening a new bug for making SMS App faster in Gaia and this one for all improvements in Gecko?
Sure, if that makes things easier.
From Gaia we are gonna make this process in two steps:
- [PhoneNumberJS]
- [Intermediate Cache]

We could keep this bug for tracking the improvements on Gecko, what do you think [:ferjm]?
We can keep this bug for tracking both improvements, Gecko and Gaia sides.
Depends on: 808815, 808819
Summary: SMS app startup is very slow with O(100) messages → [meta] Improve SMS app performance
Assignee: fabrice → nobody
Depends on: 809257
Depends on: 774621
Not blocking on meta bug then.
blocking-basecamp: + → ---
Component: Gaia → Gaia::SMS
Depends on: 813978
Duplicate of this bug: 806594
Keywords: perf
Priority: P2 → --
Whiteboard: UX-P1
Depends on: 814514
Whiteboard: UX-P1 → UX-P2
Duplicate of this bug: 819065
Depends on: 825604
Depends on: 827815
Depends on: 830222

I really hope we're not considering trying to ship a phone that takes 10 seconds and up (unbounded) to render a core part of the *phone* experience.

We need to improve this with worke that's feasible and upliftable in the v1 timeframe.  Is that work one of the dep bugs here?
Hi Chris. We are going to work on the conversation view in the following bug ! During this week we are gonna discuss some solutions with UX team, bug at the end it's gonna be related with some 'pagination' as 'What'sup' . If you have any proposal don't hesitate to add a comment to the optimization bug! Thanks!
Note that I said "upliftable in the v1 timeframe".  That bug is a major change with new UX.

Why can't we keep the current design but just insert messages into the UI in chunks instead of all at once?  That is, load 10, then load another X, ...
Hi Chris! Good news about SMS! Im testing a patch that it's capable of loading a huge list of SMS in a thread (~2500 messages) and the infinite scrolling it's working as a expected! I've upload a video and I will make the PR asap (I have to modify the 'Header' creation method). Stay tuned!
Here the Video:   ;)
That's more like it! :)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #15)
> That's more like it! :)

Chris, here we have the patch for SMS!
Could you try with your SMS DB and and this patch in order to check the performance? Everything is tracked in the following bug:
Thanks a lot!
Flags: needinfo?(jones.chris.g)
My sms db is gone :( (bug 839422).

But this is what bug 837281 is for :).
Flags: needinfo?(jones.chris.g)
Chris, the patch is merged in Master! ;)
SMS feels like a commercial product now, will go ahead and close this bug although the remaining work is still worth doing.
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.