Closed Bug 1117469 Opened 9 years ago Closed 8 years ago

[SMS][dolphin][FFOS7715 v2.1][performance] The time took for cold booting of sms app is much longer

Categories

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

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

Tracking

(tracking-b2g:-)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g -

People

(Reporter: wei.gao, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [sprd 388738 ][dp1])

Attachments

(1 file)

sms_cold_start.mp4
3.23 MB, video/mp4
Details 
*** Build Information
Gaia-Rev        17c7ad2e4919a994f0844239b483116090412dee
Gecko-Rev       4f7c43e577a1a43be0af2c02383c1c56c8c4b756
Device-Name     dolphin(ea)

*** Description
The time took for cood booting of sms app is much longer.

*** Steps to Reproduce
Pre-conditions: Call-logs(50);Contacts(250);Messages(100);Pictures(300);Songs(150);Videos(150)

1. Wait 5 minutes after device booted;
2. Click the sms icon on homescreen and start counting;
3. Stop the timer once the screen display completed.

*** Expected Results
The performance of cood booting sms app should be the same as 7715 android.

*** Actual Results
The time took for cood booting sms app is worse than 7715 android about 51%.

The average time
7715ea-FFOSv2.1 ：3.062s
Flame-FFOS      ：2.971s
7715ea-Android  : 1.514s
7715ea-FFOSv1.4 : 2.27s
Whiteboard: [sprd 388738 ]
I'd like to know exactly when you stop the timer.

Do you stop when the first screen is filled in with threads?
Or do you stop when everything stops moving (including scrollbar) ?
(In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #1)
> I'd like to know exactly when you stop the timer.
> 
> Do you stop when the first screen is filled in with threads?
> Or do you stop when everything stops moving (including scrollbar) ?

Dear Julien
We stop when the first screen is filled in with threads.
There is 100 messages, but there is only five conversations, so I think the time of scrollbar can be ignored.
Yes you're right, if you have only 5 conversations, then displaying all these conversations is the time we look for :)

I'm quite surprised by your result. I know v2.1 is slower than v2.0 (we're working on this in bug 1074783 for v2.2) but not that much.

Can you possibly test a v2.0 build on your device, so that I know if there is a regression in v1.4 -> v2.0 ?

Thanks!
Attached video sms_cold_start.mp4 — 
(In reply to Julien Wajsberg [:julienw] (PTO until 1/5) from comment #3)
> Yes you're right, if you have only 5 conversations, then displaying all
> these conversations is the time we look for :)
> 
> I'm quite surprised by your result. I know v2.1 is slower than v2.0 (we're
> working on this in bug 1074783 for v2.2) but not that much.
> 
> Can you possibly test a v2.0 build on your device, so that I know if there
> is a regression in v1.4 -> v2.0 ?
> 
> Thanks!

Dear Julien

I am so sorry ,but I can't find a way to test v2.0 build.
But I have recorded a video to show the performance of v2.1.
I think it is really slow.
Please take a look.
Thanks.
blocking-b2g: --- → 2.1S?
Whiteboard: [sprd 388738 ] → [sprd 388738 ][dp1]
If you use the "cold load time" written at the top right, then it's really a bad way to measure. We don't optimize using this number because it's not representative of what happens in real life.

And actually the number is especially bad in your specific case, and it's perfectly normal and expected. It does not mean the experience is bad for the user.

Let me explain.

What we optimize for is displaying the first panel of threads. We think this is what the user is the most interested in when he launches the SMS application.

Therefore, we delay everything until we've displayed this first panel, including loading the JS files we need for other panels. We start loading these files only once the first panel is full of thread -- or we displayed all threads, which is the case here because we only have 5 threads.


Now, you need to understand that the number written at the top right is simply the time from the application start to when we receive the "load" event. The "load" event is sent when all resources are loaded: JS, CSS, images.

So we can actually have 2 cases.

First case is:
1. Application starts
2. Gecko parses HTML, then sends "DOMContentLoaded" event. That's when we start rendering threads.
   Note that Gecko also parses CSS (possibly in parallel, or before 2., I'm not sure)
3. Gecko starts loading defered JS files.
4. Gecko finishes loading defered JS files.
5. Gecko sends "load" event.
6. We finish rendering the first panel of threads.
7. We lazy load additional JS scripts.
8. Application is ready.

Second case is:
1. Application starts
2. Gecko parses HTML, then sends "DOMContentLoaded" event. That's when we start rendering threads.
   Note that Gecko also parses CSS (possibly in parallel, or before 2., I'm not sure)
3. Gecko starts loading defered JS files.
4. Gecko finishes loading defered JS files.
5. We finish rendering the first panel of threads BEFORE the 'load' event.
6. We lazy load additional JS scripts. This _delays_ the 'load' event.
7. When the JS scripts are all loaded, Gecko sends the 'load' event.
8. Application is ready.


As you see, we have 2 cases, that only depend on whether the first panel rendering happens before or after the initial "load" event. And the cases would produce very different "load" numbers...

I would argue that second case is even better for us: it means we render the first panel faster. And yet the "load" number is likely worse.

In your case, because you have less threads, it's likely a lot faster to render the first panel, and as a result we have a much worse "load" number.


I hope it makes things clearer.

In my opinion, the only way to correctly measure launch performance is to compare 2 phones side by side. Or using a stopwatch. Or a more modern version of it: record a camera, play it in slow motion, measure using the camera. Do it several times, and use the "median" value to try to reduce the experimentation error bias.


FTR I definitely think 2.1 is slower than 1.4. I think it's due to some UX decision we made (most notably the algorithm to resize text in the header and center it). Maybe you'll be able to take some of the changes we're doing in v2.2 to impove this.
Blocks: 1123554
As triage, this is the major performance issue. Need device team to follow up.
Flags: needinfo?(shchen)
Flags: needinfo?(ehung)
FTR bug 1089920 and its dependencies are moving well, I expect them to land next week. I think you'll be able to take the new gaia-header package in v2.1 as it should work nearly the same. We still want to do a small follow-up after the big change.
We need the updated data on 2.1S. ni? William
Flags: needinfo?(whsu)
Dolphin v2.1 (512MB) test result.
Visually complete time: 3195.8 ms

Detailed information.
@ "SMS"
 - Memory Usage:
      "mozPerfMemoryAverage": {
        "app": {
          "uss": "15.780",
          "pss": "19.390",
          "rss": "32.290",
          "vsize": "86.020"
        },
 - Cold launch time:
   ~ moz-chrome-dom-loaded: 1763.2 ms
   ~ moz-app-visually-complete : 3195.8 ms
   ~ moz-content-interactive : 3984.6 ms
   ~ moz-chrome-interactive: 1879.6 ms

@ Build information:
 - Gaia-Rev        2d0df3907319edf55a643b7d4a103534579ebef0
 - Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2a3804a0911a
 - Build-ID        20150128161200
 - Version         34.0
 - Device-Name     scx15_sp7715ea
 - FW-Release      4.4.2
 - FW-Incremental  eng.cltbld.20150128.193949
 - FW-Date         Wed Jan 28 19:40:01 EST 2015

>>> >> > >>> >> > >>> >> > Conclusion >>> >> > >>> >> > >>> >> >
   Our test result approaches partner's test result.
   - Partner: 3062 ms
   - Mozilla: 3195 ms
Flags: needinfo?(whsu)
(In reply to William Hsu [:whsu] from comment #9)
> Dolphin v2.1 (512MB) test result.
> Visually complete time: 3195.8 ms
> 
> Detailed information.
> @ "SMS"
>  - Memory Usage:
>       "mozPerfMemoryAverage": {
>         "app": {
>           "uss": "15.780",
>           "pss": "19.390",
>           "rss": "32.290",
>           "vsize": "86.020"
>         },
>  - Cold launch time:
>    ~ moz-chrome-dom-loaded: 1763.2 ms
>    ~ moz-app-visually-complete : 3195.8 ms
>    ~ moz-content-interactive : 3984.6 ms
>    ~ moz-chrome-interactive: 1879.6 ms
> 
> @ Build information:
>  - Gaia-Rev        2d0df3907319edf55a643b7d4a103534579ebef0
>  - Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/2a3804a0911a
>  - Build-ID        20150128161200
>  - Version         34.0
>  - Device-Name     scx15_sp7715ea
>  - FW-Release      4.4.2
>  - FW-Incremental  eng.cltbld.20150128.193949
>  - FW-Date         Wed Jan 28 19:40:01 EST 2015
> 
> >>> >> > >>> >> > >>> >> > Conclusion >>> >> > >>> >> > >>> >> >
>    Our test result approaches partner's test result.
>    - Partner: 3062 ms
>    - Mozilla: 3195 ms

You're not measuring the same value. It's coincidence that you get a similar value.

I am really really surprised by the value you have here.
Is the Dolphin a very slow device? I use a Open C with v2.1 as my dogfooding device and it's not nearly as bad...

I think we need to profile to see what takes time here.
(In reply to Julien Wajsberg [:julienw] from comment #10)
> You're not measuring the same value. It's coincidence that you get a similar
> value.
> 
> I am really really surprised by the value you have here.
> Is the Dolphin a very slow device? I use a Open C with v2.1 as my dogfooding
> device and it's not nearly as bad...
> 
> I think we need to profile to see what takes time here.

Dear Julien

I tested the time started from clicking message icon in homescreen and ended with whole interface was stable which include the blue status bar showed. That's a standard from our QA. But I have to say the blue status bar shows too slow.
As 1.4 has no app status bar, I think the performance of 1.4 is better from this point of view.
> 
> You're not measuring the same value. It's coincidence that you get a similar
> value.
> 
> I am really really surprised by the value you have here.
> Is the Dolphin a very slow device? I use a Open C with v2.1 as my dogfooding
> device and it's not nearly as bad...
> 
> I think we need to profile to see what takes time here.

I also cannot accept the truth.
But, that's why our partner submitted the bug here, right? :)

We found the performance of Dolphin 512 MB is worse than Dolphin 256 MB when we compared the same build on these devices.
(e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1117448#c8 )
So, we need to trace back to the root cause and borrow your expertise to solve these problems.
Many thanks. :)
(In reply to Wei Gao (Spreadtrum) from comment #11)
> (In reply to Julien Wajsberg [:julienw] from comment #10)
> > You're not measuring the same value. It's coincidence that you get a similar
> > value.
> > 
> > I am really really surprised by the value you have here.
> > Is the Dolphin a very slow device? I use a Open C with v2.1 as my dogfooding
> > device and it's not nearly as bad...
> > 
> > I think we need to profile to see what takes time here.
> 
> Dear Julien
> 
> I tested the time started from clicking message icon in homescreen and ended
> with whole interface was stable which include the blue status bar showed.
> That's a standard from our QA. But I have to say the blue status bar shows
> too slow.
> As 1.4 has no app status bar, I think the performance of 1.4 is better from
> this point of view.

Yes! The pain point is the rocket bar.
NI?whsu to do extra performance comparison. (Flame 512 MB: v1.4 vs v2.1)
Flags: needinfo?(whsu)
(In reply to Wei Gao (Spreadtrum) from comment #11)
> (In reply to Julien Wajsberg [:julienw] from comment #10)
> > You're not measuring the same value. It's coincidence that you get a similar
> > value.
> > 
> > I am really really surprised by the value you have here.
> > Is the Dolphin a very slow device? I use a Open C with v2.1 as my dogfooding
> > device and it's not nearly as bad...
> > 
> > I think we need to profile to see what takes time here.
> 
> Dear Julien
> 
> I tested the time started from clicking message icon in homescreen and ended
> with whole interface was stable which include the blue status bar showed.
> That's a standard from our QA. But I have to say the blue status bar shows
> too slow.
> As 1.4 has no app status bar, I think the performance of 1.4 is better from
> this point of view.

About the app status bar (or rocket bar), please note it might related to another performance issue bug 1051852 that we start fetch message and rendering before window loaded. But rocket bar might also rendering at the same time, and this will cause message app's first view might rendered faster then rocket bar. Reverting bug 1051852 could make sure the rocket bar display first, but view rendering process would be delayed. Is rocket bar status really important for measuring the start up time?

BTW, the "Time to load" flag is really unreliable because the time would be many seconds delays than app actually loaded sometimes. Please sync with William's measuring method instead of "Time to load" flag or naked eye.
Flags: needinfo?(wei.gao)
Agree with Steve here: we don't really care about the rocket bar at launch time. What we care about is displaying the threads and interacting with them. (see also bug 1125601 which is somewhat related)
Thanks for your suggestions and comments.

But, as a user, these are the first time launch experience of SMS app.

By the way, confirming with partner, they are using high-speed camera to measurement the performance.
I used test-perf (10 runs per app), and sometimes used high-speed camera to compare the data and prove the accuracy of visually-complete time .
So, you can say that the "moz-chrome-dom-loaded" time, "moz-content-interactive" time, and "moz-chrome-interactive" time are unreliable.
But, I think the "moz-app-visually-complete" is worth reference.

Many thanks. :)
(In reply to William Hsu [:whsu] from comment #17)
> Thanks for your suggestions and comments.
> 
> But, as a user, these are the first time launch experience of SMS app.
> 
> By the way, confirming with partner, they are using high-speed camera to
> measurement the performance.
Sorry for the typo...
I mean "measure the performance". :)
Flags: needinfo?(whsu)
Flags: needinfo?(whsu)
I'm not saying anything else. I'm saying someone should get a profile of the cold launch action to know what's going on. I'm bad at profiling so I'd prefer that someone else does it.
(In reply to Steve Chung [:steveck] from comment #15)
> About the app status bar (or rocket bar), please note it might related to
> another performance issue bug 1051852 that we start fetch message and
> rendering before window loaded. But rocket bar might also rendering at the
> same time, and this will cause message app's first view might rendered
> faster then rocket bar. Reverting bug 1051852 could make sure the rocket bar
> display first, but view rendering process would be delayed. Is rocket bar
> status really important for measuring the start up time?
> 
> BTW, the "Time to load" flag is really unreliable because the time would be
> many seconds delays than app actually loaded sometimes. Please sync with
> William's measuring method instead of "Time to load" flag or naked eye.

Dear Steve

I think from the user perspective, if the interface no matter what aspect except dynamic pictures is still changing, I have reason to think this app is still in the process of starting.
So from this point of view, we think the rocket bar belongs to the app.
In fact, the main reason is our QA stoped his watch untill the whole interface became stable.
Flags: needinfo?(wei.gao)
(In reply to William Hsu [:whsu] from comment #14)
> NI?whsu to do extra performance comparison. (Flame 512 MB: v1.4 vs v2.1)

Summarizing the all data.

From partner,
 - 7715ea-FFOSv2.1 ：3.062s
 - Flame-FFOS      ：2.971s
 - 7715ea-Android  : 1.514s
 - 7715ea-FFOSv1.4 : 2.27s

From Mozilla,
 - 7715ea-FFOSv2.1：    3.1958s
 - Flame v1.4 (512 MB): 1.880s  (Mean time to show message app)
 - Flame v2.1 (512 MB): 1.7325s (Mean time to show message app)
 - Flame v2.1 (512 MB): 2.7033s (Mean time to show message app with rocket bar)

@ Build information
 - Flame v1.4 (JB, single-core with 512 MB)
  ~ Gaia-Rev        04265f42139a7a5c611c45e4869582642927e835
  ~ Gecko-Rev       af6e951d18ca
  ~ Build-ID        20150201160228
  ~ Version         30.0

 - Flame v2.1 (KK, single-core with 512 MB)
  ~ Gaia-Rev        63f291df9b9ad8498fb8fc7fb8bf070524406a5c
  ~ Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/70b8982a523d
  ~ Build-ID        20150202161206
  ~ Version         34.0
  ~ Device-Name     flame
  ~ FW-Release      4.4.2
  ~ Bootloader      L1TC100118D0


>>>>>>>>>>>>>>>> Comments >>>>>>>>>>>>>>>>
1. Compare the UI interaction of sms (cold launch Flame v1.4 & Flame v2.1), you can see that rocket bar increase the sms app cold launch time.
Flags: needinfo?(whsu)
(In reply to William Hsu [:whsu] from comment #21)
> (In reply to William Hsu [:whsu] from comment #14)
> > NI?whsu to do extra performance comparison. (Flame 512 MB: v1.4 vs v2.1)
> 
> ...
> 
> >>>>>>>>>>>>>>>> Comments >>>>>>>>>>>>>>>>
> 1. Compare the UI interaction of sms (cold launch Flame v1.4 & Flame v2.1),
>    you can see that rocket bar increase the sms app cold launch time.
  2. Compare the cold launch time with different devices (Flame v2.1 & Dolphin v2.1s),
     it seems to be a device-specific problem.

Many thanks.
(In reply to William Hsu [:whsu] from comment #22)
> > >>>>>>>>>>>>>>>> Comments >>>>>>>>>>>>>>>>
> > 1. Compare the UI interaction of sms (cold launch Flame v1.4 & Flame v2.1),
> >    you can see that rocket bar increase the sms app cold launch time.
>   2. Compare the cold launch time with different devices (Flame v2.1 &
> Dolphin v2.1s),
>      it seems to be a device-specific problem.
> 
> Many thanks.
Sorry William:
  the QA test rule is that Mean time to show message app with status bar paint done. So it too far from Android, so please help try to think out of box what to do anything else we can.
  So far, the status bar from system is too slow.
Thank you
Flags: needinfo?(whsu)
I believe that Steven has better suggestion when we triage this bug this Thursday (2/5).
Thanks.
Flags: needinfo?(whsu)
(In reply to siiaceon from comment #23)
> (In reply to William Hsu [:whsu] from comment #22)
> > > >>>>>>>>>>>>>>>> Comments >>>>>>>>>>>>>>>>
> > > 1. Compare the UI interaction of sms (cold launch Flame v1.4 & Flame v2.1),
> > >    you can see that rocket bar increase the sms app cold launch time.
> >   2. Compare the cold launch time with different devices (Flame v2.1 &
> > Dolphin v2.1s),
> >      it seems to be a device-specific problem.
> > 
> > Many thanks.
> Sorry William:
>   the QA test rule is that Mean time to show message app with status bar
> paint done. So it too far from Android, so please help try to think out of
> box what to do anything else we can.
>   So far, the status bar from system is too slow.
> Thank you

Hi Siiaceon -

As Julien mentioned, we are working on Bug#1125601 which will again make user to interact with the message thread before the rocket bar finish painting. I think as long as the users can interact with the message thread, it means that the application loading is complete. So instead of improving the painting time of rocketbar, do you think it make sense we just focus on Bug#1125601?

Thanks
Flags: needinfo?(siiaceon.cao)
Flags: needinfo?(ehung)
Flags: needinfo?(chens)
Add Dolphin v1.4 (256MB) and Dolphin v1.4 (512 MB) test result

> From partner,
>  - 7715ea-FFOSv2.1 ：3.062s
>  - Flame-FFOS      ：2.971s
>  - 7715ea-Android  : 1.514s
>  - 7715ea-FFOSv1.4 : 2.27s
> 
> From Mozilla,
>  - 7715ea-FFOSv2.1  (512 MB)：3.1958s
   - 7715ea-FFOSv1.4  (512 MB)：2.866s 
   - 7715ga-FFOSv1.4  (256 MB): 2.776s   
>  - Flame v1.4       (512 MB): 1.880s  (Mean time to show message app)
>  - Flame v2.1       (512 MB): 1.7325s (Mean time to show message app)
>  - Flame v2.1       (512 MB): 2.7033s (Mean time to show message app with rocket bar)
> 
> @ Build information
>  - Flame v1.4 (JB, single-core with 512 MB)
>   ~ Gaia-Rev        04265f42139a7a5c611c45e4869582642927e835
>   ~ Gecko-Rev       af6e951d18ca
>   ~ Build-ID        20150201160228
>   ~ Version         30.0
> 
>  - Flame v2.1 (KK, single-core with 512 MB)
>   ~ Gaia-Rev        63f291df9b9ad8498fb8fc7fb8bf070524406a5c
>   ~ Gecko-Rev      
>   ~ https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/70b8982a523d
>   ~ Build-ID        20150202161206
>   ~ Version         34.0
>   ~ Device-Name     flame
>   ~ FW-Release      4.4.2
>   ~ Bootloader      L1TC100118D0

   - Dolphin v1.4 (512 MB)
     ~ Gaia-Rev        04265f42139a7a5c611c45e4869582642927e835
     ~ Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/93a7fd645e82
     ~ Build-ID        20150204160202
     ~ Version         30.0
     ~ Device-Name     scx15_sp7715ea
     ~ FW-Release      4.4.2

   - Dolphin v1.4 (256MB)
     ~ Gaia-Rev        04265f42139a7a5c611c45e4869582642927e835
     ~ Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/93a7fd645e82
     ~ Build-ID        20150204160202
     ~ Version         30.0
     ~ Device-Name     scx15_sp7715ga
     ~ FW-Release      4.4.2
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #25)
> (In reply to siiaceon from comment #23)
> > (In reply to William Hsu [:whsu] from comment #22)
> > > > >>>>>>>>>>>>>>>> Comments >>>>>>>>>>>>>>>>
> > > > 1. Compare the UI interaction of sms (cold launch Flame v1.4 & Flame v2.1),
> > > >    you can see that rocket bar increase the sms app cold launch time.
> > >   2. Compare the cold launch time with different devices (Flame v2.1 &
> > > Dolphin v2.1s),
> > >      it seems to be a device-specific problem.
> > > 
> > > Many thanks.
> > Sorry William:
> >   the QA test rule is that Mean time to show message app with status bar
> > paint done. So it too far from Android, so please help try to think out of
> > box what to do anything else we can.
> >   So far, the status bar from system is too slow.
> > Thank you
> 
> Hi Siiaceon -
> 
> As Julien mentioned, we are working on Bug#1125601 which will again make
> user to interact with the message thread before the rocket bar finish
> painting. I think as long as the users can interact with the message thread,
> it means that the application loading is complete. So instead of improving
> the painting time of rocketbar, do you think it make sense we just focus on
> Bug#1125601?
> 
> Thanks

Vance: 
  we faild to comunicate with test that without statusbar test rule. next step, we r&d are going to test without statusbar, to argue with test again.
  So please vance help arrange this issue for sometime to load or display list faster. Now we had try to only display the first 7 item fast, but not reach the low target from test.
Flags: needinfo?(siiaceon.cao)
we have a try make it better and also conmunicated with QA, waiting for the result
Dear Julien

I am wondering why our ffos use asyncStorage to store Drafts instead of indexDB which is used by normal messages storage.
Is there any special consideration?
But I have to say, getting drafts from asyncStorage waste longer time.

asyncStorage.getItem('draft index', function(records) {});

Is there anything we can improve the drafts stroage performance?
Thanks so much.
Flags: needinfo?(felash)
(In reply to Wei Gao (Spreadtrum) from comment #29)
> Dear Julien
> 
> I am wondering why our ffos use asyncStorage to store Drafts instead of
> indexDB which is used by normal messages storage.
> Is there any special consideration?
> But I have to say, getting drafts from asyncStorage waste longer time.
> 
> asyncStorage.getItem('draft index', function(records) {});
> 
> Is there anything we can improve the drafts stroage performance?
> Thanks so much.

Oh, I just found the asyncStorage also used indexDB. :)
But I still doubt why it is so slower than getThread.
I will go on research.
I found if we only get three drafts, we only need 0.4s.
But if we get drafts and get threads list at the same time, such as we have five threads among which there are two normal threads and three drafts, then getting drafts will become a great time 1.0s.
I don't know how to deal with this.
Our QA use two normal threads and three drafts threads to test the performance of SMS like I say in Comment 31.
But we can clearly see the drafts threads is much slower than normal messages.
You are right, asyncStorage is implemented based on indexDB. We are grateful for your investigation here, but just a reminder that please simplify your test case instead of testing right in the message app. There are 4 DB asscessing data at the same time(message, draft, contact and facebook) and rendering in different way for actual thread and drafts. So please make sure you are "only" measuring getthread api/asyncStorage callback duration without any rendering or other logic while profiling.
Flags: needinfo?(felash)
(In reply to Steve Chung [:steveck] from comment #33)
> You are right, asyncStorage is implemented based on indexDB. We are grateful
> for your investigation here, but just a reminder that please simplify your
> test case instead of testing right in the message app. There are 4 DB
> asscessing data at the same time(message, draft, contact and facebook) and
> rendering in different way for actual thread and drafts. So please make sure
> you are "only" measuring getthread api/asyncStorage callback duration
> without any rendering or other logic while profiling.

Hi Steve

I understand your mean.
But from the user perspective, draft threads and normal message threads are same.
If drafts threads load slow, user will also think the whole sms application is launched slow. After all, most average users only care for the whole interface.
How do you think about it?
Thanks.
Hey,

When loading the SMS app, we need data from several sources:
* Messages database: an IndexedDB that is inside Gecko
* Drafts: an IndexedDB kept in Gaia
* Contacts: an IndexedDB that is inside Gecko... but not the same one than Messages, of course
* Facebook Contacts: (I'm not really sure) either a DataStore (which is backed by IndexedDB in Gecko) or IndexedDb or both
* Settings: an IndexedDB in Gecko

All these sources compete with each other.

The only real solution (IMO) is to have a specialized IndexedDB in the SMS application that would hold all this data. That would be a cache and would also allow us to do a lot of useful things (more lazy loading, searching, etc). But this is a _huge_ work. We'll need to eventually do it.


So here is an idea to do an hacky fix.
We try to load the Messages as early as possible in the boot process. But we start Drafts request later. Maybe you can try to run Drafts.request() very early, maybe inside drafts.js itself so that it runs asap, and see if this improves the situation? Likely this will finish earlier but other tasks will be delayed, so because it's a trade off we need to measure and see if this looks better.


If someone has enough time, we can try to stuff the first panel (including threads) in the asyncStorage data, and try to keep it in sync when receiving/sending/deleting messages. This wouldn't be a real DB where we could do DB search and advanced functionality, but this could be good enough to improve the first panel rendering. And maybe we'd actually need both.
Thanks Julien for your good suggestion, I hope SPRD can try it and share results here. SMS app is widely tested in certification and improvements are more than welcome.
(In reply to Julien Wajsberg [:julienw] from comment #35)

Dear Julien

Thanks for your kindly suggestions. I have tested it locally.

> We try to load the Messages as early as possible in the boot process. But we
> start Drafts request later. Maybe you can try to run Drafts.request() very
> early, maybe inside drafts.js itself so that it runs asap, and see if this
> improves the situation? Likely this will finish earlier but other tasks will
> be delayed, so because it's a trade off we need to measure and see if this
> looks better.

Do you mean runing Drafts.request() earlier as soon as the sms cold launch?
This is a easy method, but through my test, this can't shorten the cold booting time.
Because many operations need to be handled, after runing Drafts.request() earlier, the drafts are loaded slower than normal. I can't find any improvement about this.

> If someone has enough time, we can try to stuff the first panel (including
> threads) in the asyncStorage data, and try to keep it in sync when
> receiving/sending/deleting messages.

I found the indexDB using in Gaia is slower than using in Gecko.
So I doesn't think using asyncStorage to storage threads is a good solution.

However the loading speed of threads storaged in Gecko is very fast.
So could we make the drafts also in Gecko like threads?
Thanks.
(In reply to Wei Gao (Spreadtrum) from comment #37)

> > If someone has enough time, we can try to stuff the first panel (including
> > threads) in the asyncStorage data, and try to keep it in sync when
> > receiving/sending/deleting messages.
> 
> I found the indexDB using in Gaia is slower than using in Gecko.
> So I doesn't think using asyncStorage to storage threads is a good solution.
> 
> However the loading speed of threads storaged in Gecko is very fast.
> So could we make the drafts also in Gecko like threads?
> Thanks.

There is no reason indexedDB is faster in Gecko than in Gaia.
I think the loading of threads is fast because it happens alone.

The idea is to store a cache in asyncStorage, so that we can load it _alone_ without loading anything else in parallel.
(In reply to Julien Wajsberg [:julienw] from comment #38)
> The idea is to store a cache in asyncStorage, so that we can load it _alone_
> without loading anything else in parallel.

Thanks.
What does store a cache in asyncStorage mean? When we load drafts successfully, there will be a cache in drafts.js. But we can't preserve the cache when app is closed. :(
Could you describe your mean clearly again?
This is an idea i have for some time but I never had the time to work on it yet.

Our main bottleneck is that we have to access 5 different databases at launch time: messages in gecko, contacts in gecko, drafts, facebook contacts, settings.

So the idea is to cache the result to one single database that would keep all the data we need at launch time (including the contacts information, pictures, etc) so that we just need to get information from this database.

We'll need to synchronize and update the view if necessary -- especially for contacts and settings. But this seldom changes. We can have new contacts, but the first threads in SMS are usually from known contacts that don't change often.

Main problem is... this is quite some work ;) I can find some time next week to at least experiment and see if this makes things faster.
Summary: [SMS][dolphin][FFOS7715 v2.1][performance] The time took for cood booting of sms app is much longer → [SMS][dolphin][FFOS7715 v2.1][performance] The time took for cold booting of sms app is much longer
Dear Julien

Thanks for your work.

BTW, may I ask a question?
When I transfer the script file in '/shared/elements/' from index.html to LazyLoader, the two js files can't be executed.
But if other js files not included in '/shared/elements/' in this way can be loaded normal.
I don't know why.
Could you help me?
Thanks very much.


diff --git a/apps/sms/index.html b/apps/sms/index.html
index 5a9aaf6..67578fa 100644
--- a/apps/sms/index.html
+++ b/apps/sms/index.html
@@ -31,8 +31,7 @@
     <link rel="resource" type="application/l10n" href="shared/locales/date.ini">
     <link rel="resource" type="application/l10n" href="shared/locales/sim_picker.ini">
     <!-- Web Components -->
-    <script defer src="/shared/elements/config.js"></script>
-    <script defer src="/shared/elements/gaia-header/dist/script.js"></script>
     <link rel="stylesheet" type="text/css" href="app://theme.gaiamobile.org/shared/elements/gaia-theme/style.css" />
     <!-- <link rel="stylesheet" type="text/css" href="/shared/elements/gaia-icons/style.css" /> -->
     <!-- Shared code -->
diff --git a/apps/sms/js/startup.js b/apps/sms/js/startup.js
index 2984e0a..4767d99 100644
--- a/apps/sms/js/startup.js
+++ b/apps/sms/js/startup.js
@@ -11,6 +11,8 @@
 
 var Startup = {
   _lazyLoadScripts: [
+    '/shared/elements/config.js',
+    '/shared/elements/gaia-header/dist/script.js',
     '/shared/js/settings_listener.js',
     '/shared/js/sim_picker.js',
     '/shared/js/mime_mapper.js',
Because that, I have to copy the whole '/shared/elements/' folder to 'apps/sms/', and then it can work.
But I think it is not a good way.
So does the '/shared/elements/' folder has special restrictions?
Thanks.
I can make it work normal now.
Maybe I should copy the two into <!-- Lazy load scripts  ...  --> list in index.html, althrough I don't know why.
In our build system, we have a very simple way to determine if we need to copy files from /shared: [1]. This is not elegant, but it works well enough that we don't want to change it ;)

[1] https://github.com/mozilla-b2g/gaia/blob/0a0c6008866510b88d9a75bd30fbd249bfea9b3c/build/webapp-shared.js#L306-L320

Note that I'd advise against lazyloading these files; it should accordingly decrease the load time, but there will be visual issues.
(In reply to Julien Wajsberg [:julienw] from comment #45)
> In our build system, we have a very simple way to determine if we need to
> copy files from /shared: [1]. This is not elegant, but it works well enough
> that we don't want to change it ;)
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/
> 0a0c6008866510b88d9a75bd30fbd249bfea9b3c/build/webapp-shared.js#L306-L320
> 
> Note that I'd advise against lazyloading these files; it should accordingly
> decrease the load time, but there will be visual issues.

Thank Julien
I know the visual issue. I will try to do something make sense to workaround it.
Thanks
Been fixed in partner side.
blocking-b2g: 2.1S? → ---
Steven, I'm curious to know if partner "fixed" it like said in previous comment?
Flags: needinfo?(styang)
(In reply to Julien Wajsberg [:julienw] from comment #48)
> Steven, I'm curious to know if partner "fixed" it like said in previous
> comment?

I modified many small places. Actually the most effective way was made a false sms gaia-header which can make cpu provided more resource to load indexDB and others. I have to say the sms gaia-header seems too heavy to load. After a while, I let the real sms header cover the false one.
It is really a workaround solution but very effective. Please forgive me. :)
Thanks.
Clear need information since Wei Gao already provide the answer to Julien's question
Flags: needinfo?(styang)
(In reply to Wei Gao (Spreadtrum) from comment #49)
> (In reply to Julien Wajsberg [:julienw] from comment #48)
> > Steven, I'm curious to know if partner "fixed" it like said in previous
> > comment?
> 
> I modified many small places. Actually the most effective way was made a
> false sms gaia-header which can make cpu provided more resource to load
> indexDB and others. I have to say the sms gaia-header seems too heavy to
> load. After a while, I let the real sms header cover the false one.
> It is really a workaround solution but very effective. Please forgive me. :)
> Thanks.

Okay !

I hope the changes we made to gaia-header in v2.2 will be as effective.
Dear Julien

FFOSv2.1 doesn't support import and export sms from sim card.
Does v2.2 or later version support it?
Thanks.
Flags: needinfo?(felash)
Wei, I don't think this is the right place to ask this question.

But no, no work has been done to support this. If you want the feature, please file a bug in the "RIL" component.
Flags: needinfo?(felash)
(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #53)
> Wei, I don't think this is the right place to ask this question.
> 
> But no, no work has been done to support this. If you want the feature,
> please file a bug in the "RIL" component.
It is already in: https://bugzilla.mozilla.org/show_bug.cgi?id=900312
(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #53)
> Wei, I don't think this is the right place to ask this question.

Sorry, I don't know a better way to communication with you. :(
If I have some other question, I will file a new bug?
Thanks.
I think we have dedicated people working with partners in Mozilla, it's best if you can contact them directly, especially when planning ahead features.
(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #56)
> I think we have dedicated people working with partners in Mozilla, it's best
> if you can contact them directly, especially when planning ahead features.

Ok, thanks for your suggestion.
Have a nice day!
tracking-b2g: --- → -
We have other bugs for this, let's close this one as it was opened by a partner that fixed it on their side.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: