Closed Bug 1117445 Opened 9 years ago Closed 6 years ago

[FFOS7715 v2.1][performance] it is slow to start up by normal boot-strap or restart in FFOS2.1

Categories

(Firefox OS Graveyard :: Performance, defect, P4)

Product:
Firefox OS Graveyard
Component:
Performance
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(tracking-b2g:-)

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g -

People

(Reporter: ben.song, Unassigned)

References

Details

(Keywords: perf)

Attachments

(6 files, 1 obsolete file)

bootchart-dolphin-v1.4.png
117.99 KB, image/png
Details
bootchart-dolphin-v2.1s.png
118.16 KB, image/png
Details
bootlogs_v1.4
206.74 KB, text/x-vhdl
Details
bootlogs_v2.1
200.42 KB, text/x-vhdl
Details
boot_log.tar.gz
86.25 KB, application/x-gzip
Details
WIP - SettingsCache
46 bytes, text/x-github-pull-request
alive
: feedback+
Details | Review 
Reproduce step:

1.Start up the phone by powerkey.
2.Start time until the screen lights up： t1.
3.Stop time until homescreen icons appear completely: t2.
4.Conpare this time,t2-t1.


Ideal result:

this start up time is not slower than others.

Actual result:

this start up time is slower than 1.4 and android.

7715FFOSv2.1: 36.37/35.94/35.67 平均35.993
7715Android: 27.86/26.26/27.4 平均27.17
FlameFFOSV2.1: 37.347/37.549/37.413 平均37.436
7715FFOSv1.4: 33.337/34.125/33.469 平均33.643

Reproduce rate: 10/10
Compare the power on time between two different OS is meaningless, and since 7715 2.1 is already faster than Flame 2.1, I think we are good here

Thanks

Vance
Dear Vance, Shawn,

In start-up of v2.1, nuwa process would fork a process of preallocated, and give it to a new process of build-in-keyboard. This would take 4~6s of start-up time. Could we not load this process or load it later ?

Thanks.
Flags: needinfo?(sku)
Hi Danny:
 Please help check this issue with comment 2 first.

Thanks!!
Shawn
Flags: needinfo?(sku) → needinfo?(dliang)
(In reply to ben.song from comment #2)
> Dear Vance, Shawn,
> 
> In start-up of v2.1, nuwa process would fork a process of preallocated, and
> give it to a new process of build-in-keyboard. This would take 4~6s of
> start-up time. Could we not load this process or load it later ?
> 
> Thanks.

I don't think so. By my test, build-in-keyboard is forked after homescreen. That means it won't impact the boot up time. Do you have further information to prove the 4~6s is caused by build-in-keyboard?
Flags: needinfo?(ben.song)
(In reply to Danny Liang [:dliang] from comment #4)
> (In reply to ben.song from comment #2)
> > Dear Vance, Shawn,
> > 
> > In start-up of v2.1, nuwa process would fork a process of preallocated, and
> > give it to a new process of build-in-keyboard. This would take 4~6s of
> > start-up time. Could we not load this process or load it later ?
> > 
> > Thanks.
> 
> I don't think so. By my test, build-in-keyboard is forked after homescreen.
> That means it won't impact the boot up time. Do you have further information
> to prove the 4~6s is caused by build-in-keyboard?

Dear Danny,

I modify keyboard.launch-on-boot in gaia/build/config/common_settings.json to false, but the start-up time reduce a little. I found the reason is homescreen_ready come too late in homescreen_launch.I would find others consuming point.

Could I any you another question ?

Could I reduce the time of NUWA_FORK_WAIT_DURATION_MS in PreallocatedProcessManager.cpp and the value of dom.ipc.processPrelaunch.delayMs in b2g.js ?

Thanks.
Flags: needinfo?(vchen)
Flags: needinfo?(ben.song)
(In reply to ben.song from comment #5)
> (In reply to Danny Liang [:dliang] from comment #4)
> > (In reply to ben.song from comment #2)
> > > Dear Vance, Shawn,
> > > 
> > > In start-up of v2.1, nuwa process would fork a process of preallocated, and
> > > give it to a new process of build-in-keyboard. This would take 4~6s of
> > > start-up time. Could we not load this process or load it later ?
> > > 
> > > Thanks.
> > 
> > I don't think so. By my test, build-in-keyboard is forked after homescreen.
> > That means it won't impact the boot up time. Do you have further information
> > to prove the 4~6s is caused by build-in-keyboard?
> 
> Dear Danny,
> 
> I modify keyboard.launch-on-boot in gaia/build/config/common_settings.json
> to false, but the start-up time reduce a little. I found the reason is
> homescreen_ready come too late in homescreen_launch.I would find others
> consuming point.
> 
> Could I any you another question ?
> 
> Could I reduce the time of NUWA_FORK_WAIT_DURATION_MS in
> PreallocatedProcessManager.cpp and the value of
> dom.ipc.processPrelaunch.delayMs in b2g.js ?
> 

I don't think it's main root reason to cause performance low on v2.1s. There are same delay on both v1.4 and v2.1s. So I suspect there might be other problem in this case. Do you use bootchart (http://www.bootchart.org/) to analyse this bug? It's a good tool to profile boot-time performance.

> Thanks.
(In reply to Danny Liang [:dliang] from comment #6)
> (In reply to ben.song from comment #5)
> > (In reply to Danny Liang [:dliang] from comment #4)
> > > (In reply to ben.song from comment #2)
> > > > Dear Vance, Shawn,
> > > > 
> > > > In start-up of v2.1, nuwa process would fork a process of preallocated, and
> > > > give it to a new process of build-in-keyboard. This would take 4~6s of
> > > > start-up time. Could we not load this process or load it later ?
> > > > 
> > > > Thanks.
> > > 
> > > I don't think so. By my test, build-in-keyboard is forked after homescreen.
> > > That means it won't impact the boot up time. Do you have further information
> > > to prove the 4~6s is caused by build-in-keyboard?
> > 
> > Dear Danny,
> > 
> > I modify keyboard.launch-on-boot in gaia/build/config/common_settings.json
> > to false, but the start-up time reduce a little. I found the reason is
> > homescreen_ready come too late in homescreen_launch.I would find others
> > consuming point.
> > 
> > Could I any you another question ?
> > 
> > Could I reduce the time of NUWA_FORK_WAIT_DURATION_MS in
> > PreallocatedProcessManager.cpp and the value of
> > dom.ipc.processPrelaunch.delayMs in b2g.js ?
> > 
> 
> I don't think it's main root reason to cause performance low on v2.1s. There
> are same delay on both v1.4 and v2.1s. So I suspect there might be other
> problem in this case. Do you use bootchart (http://www.bootchart.org/) to
> analyse this bug? It's a good tool to profile boot-time performance.
> 
> > Thanks.

Dear Danny,

How to use bootchart in FFOS, does it like used in android ?

Thanks.
(In reply to ben.song from comment #7)
> (In reply to Danny Liang [:dliang] from comment #6)
> > (In reply to ben.song from comment #5)
> > > (In reply to Danny Liang [:dliang] from comment #4)
> > > > (In reply to ben.song from comment #2)
> > > > > Dear Vance, Shawn,
> > > > > 
> > > > > In start-up of v2.1, nuwa process would fork a process of preallocated, and
> > > > > give it to a new process of build-in-keyboard. This would take 4~6s of
> > > > > start-up time. Could we not load this process or load it later ?
> > > > > 
> > > > > Thanks.
> > > > 
> > > > I don't think so. By my test, build-in-keyboard is forked after homescreen.
> > > > That means it won't impact the boot up time. Do you have further information
> > > > to prove the 4~6s is caused by build-in-keyboard?
> > > 
> > > Dear Danny,
> > > 
> > > I modify keyboard.launch-on-boot in gaia/build/config/common_settings.json
> > > to false, but the start-up time reduce a little. I found the reason is
> > > homescreen_ready come too late in homescreen_launch.I would find others
> > > consuming point.
> > > 
> > > Could I any you another question ?
> > > 
> > > Could I reduce the time of NUWA_FORK_WAIT_DURATION_MS in
> > > PreallocatedProcessManager.cpp and the value of
> > > dom.ipc.processPrelaunch.delayMs in b2g.js ?
> > > 
> > 
> > I don't think it's main root reason to cause performance low on v2.1s. There
> > are same delay on both v1.4 and v2.1s. So I suspect there might be other
> > problem in this case. Do you use bootchart (http://www.bootchart.org/) to
> > analyse this bug? It's a good tool to profile boot-time performance.
> > 
> > > Thanks.
> 
> Dear Danny,
> 
> How to use bootchart in FFOS, does it like used in android ?
> 
> Thanks.

Yes, it's same as android.
Flags: needinfo?(dliang)
Blocks: 1123554
bootchart for dolphin v1.4
bootchart for dolphin v2.1s
By bootchart, we found b2g consume more CPU time on v2.1s. Rex will help to do further investigation and update later.
Flags: needinfo?(rhung)
(In reply to Danny Liang [:dliang] from comment #10)
> Created attachment 8552922 [details]
> bootchart-dolphin-v2.1s.png
> 
> bootchart for dolphin v2.1s

Dear Danny,

Thanks for you help, base on system module code i find some consuming point:

1.SettingsLock used is too low during start-up, and consuming 3s or more, could we use other method to instead of it ?

2.HomescreenWindow start too late, and it load ended more lately.

3.In ftu_launcher.js, request of VersionHelp.getVersionInfo get success information too late.

Thanks.
Update boot time break down as follow for both v1.4 and v2.1:
I added debug logs at some critical check points of boot flow, and got the following result. According to this comparison, we found that:
1. The time of converting preallocated app to homescreen app in v2.1(15 seconds) is later than in v1.4(8 seconds). Need to further break down gaia layer boot flow for v1.4 and v2.1 and compare them.
2. The execution of forking Nuwa process is 6 seconds(v1.4) and 7 seconds(v2.1), instead of 1 second, after the corresponding task is created and queued. Need to further clarify if this time cost can be improved.

Will attach full logs for reference later.

[v1.4]
01-27 04:11:44.950 I/boottime(  129): b2g: b2g process start
01-27 04:11:46.770 I/boottime(  129): b2g: Create delayed work to fork Nuwa process.
            ^^^^^^ point 2
01-27 04:11:52.780 I/boottime(  129): b2g: Start to fork Nuwa process >>>
            ^^^^^^ point 2
01-27 04:11:52.780 I/boottime(  129): b2g: Post a task for Nuwa create, LaunchAndWaitForProcessHandle
01-27 04:11:52.830 I/boottime(  515): Nuwa: Nuwa process start
01-27 04:11:52.830 I/boottime(  129): b2g: Start to fork Nuwa process <<<
01-27 04:11:56.480 I/boottime(  129): b2g: Got Nuwa ready
01-27 04:11:56.480 I/boottime(  129): b2g: Start to fork content process >>>
01-27 04:11:56.480 I/boottime(  129): b2g: Start to fork content process <<<
01-27 04:11:56.500 I/boottime(  515): Nuwa: Request of content process fork
01-27 04:11:57.190 I/boottime(  515): Nuwa: Content process fork >>>
01-27 04:11:57.300 I/boottime(  515): Nuwa: Content process fork <<<
01-27 04:11:57.320 I/boottime(  571): Nuwa: Set Preallocated app as process name
01-27 04:11:57.330 I/boottime(  571): Nuwa: Content process fork <<<
01-27 04:11:57.410 I/boottime(  129): b2g: Post a task for Nuwa create, LaunchAndWaitForProcessHandle
01-27 04:11:57.420 I/boottime(  129): b2g: Add ContentParent to spare process list
            ^^^^^^ point 1
01-27 04:12:05.390 I/boottime(  129): b2g: Get ContentParent from spare process list
            ^^^^^^ point 1
[v2.1]
01-27 03:04:01.940 I/boottime(  129): b2g: b2g process start
01-27 03:04:03.420 I/boottime(  301): Nuwa: Nuwa process start
01-27 03:04:03.520 I/boottime(  301): Nuwa: Run pthread_cond_wait >>>
01-27 03:04:04.160 I/boottime(  129): b2g: Create delayed work to fork Nuwa process.
            ^^^^^^ point 2
01-27 03:04:11.070 I/boottime(  129): b2g: Start to fork Nuwa process >>>
            ^^^^^^ point 2
01-27 03:04:11.080 I/boottime(  129): b2g: Post a task for Nuwa create, LaunchAndWaitForProcessHandle
01-27 03:04:11.080 I/boottime(  129): b2g: Start to fork Nuwa process <<<
01-27 03:04:11.100 I/boottime(  129): b2g: Send MSG via IPDL to Nuwa, AsyncSendLoad
01-27 03:04:11.110 I/boottime(  301): Nuwa: Run pthread_cond_wait <<<
01-27 03:04:11.110 I/boottime(  301): Nuwa: task->DoWork >>>
01-27 03:04:14.520 I/boottime(  301): Nuwa: Run main thread loop >>>
01-27 03:04:14.760 I/boottime(  129): b2g: Got Nuwa ready
01-27 03:04:14.760 I/boottime(  129): b2g: Start to fork content process >>>
01-27 03:04:14.760 I/boottime(  129): b2g: Start to fork content process <<<
01-27 03:04:14.780 I/boottime(  301): Nuwa: Request of content process fork
01-27 03:04:15.370 I/boottime(  301): Nuwa: Content process fork >>>
01-27 03:04:15.440 I/boottime(  301): Nuwa: Content process fork <<<
01-27 03:04:15.480 I/boottime(  582): Nuwa: Set Preallocated app as process name
01-27 03:04:15.490 I/boottime(  582): Nuwa: Content process fork <<<
01-27 03:04:15.490 I/boottime(  129): b2g: Post a task for Nuwa create, LaunchAndWaitForProcessHandle
01-27 03:04:15.510 I/boottime(  129): b2g: Add ContentParent to spare process list
            ^^^^^^ point 1
01-27 03:04:31.090 I/boottime(  129): b2g: Get ContentParent from spare process list
            ^^^^^^ point 1
Flags: needinfo?(rhung)
Attached file bootlogs_v1.4 — 

    
    

    
  

      
      
      
      

        Attached file
          
        bootlogs_v2.1
        — 
      

    


  

    
    

    
  
Hi Chens,
Could you have time to check/comment the difference of homescreen between v1.4 and v2.1s?
By Rex's analysis on comment 13, the main gap should be caused by homescreen app.
Flags: needinfo?(chens)

    
    

    
  
Homescreen is totally different between 1.4 and 2.1, we have changed default home to vertical homescreen since 2.0. I think we should add some logs in to compare when it gets 'homescreen-ready' event, would you help to apply these patch? thanks!

1.4: https://github.com/shamenchens/gaia/commit/63f50059f75640cecca3ff152f929afcf84a0e6a
2.1: https://github.com/shamenchens/gaia/commit/3da05f1587f8cbcddccbd14c9946173753b7d35f
Flags: needinfo?(chens)

    
    

    
  
Hi Ben Song -

As mentioned on Comment#17, could you help on this? Just apply the patches onto 1.4 and 2.1 and then get the log of boot start. 

Thanks for your help
Flags: needinfo?(ben.song)

    
    

    
  
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #18)
> Hi Ben Song -
> 
> As mentioned on Comment#17, could you help on this? Just apply the patches
> onto 1.4 and 2.1 and then get the log of boot start. 
> 
> Thanks for your help

Dear Vance,

OK, I would do it and upload the log later.

Thanks.
Flags: needinfo?(ben.song)

    
    

    
  
Danny and Ben, 

Could you both try this patch on 2.1 and share the result? 
https://github.com/shamenchens/gaia/commit/3b65ec4a955317502c7c0a7cb8eef5be343ea603

This patch tries to use SettingsCache to speedup system app bootup time, idea is borrowed from John who works on smart screen system bootup performance (bug 1090810). Ideally this could save 3+ secs.
Flags: needinfo?(dliang)
Flags: needinfo?(ben.song)

    
    

    
  
(In reply to Sherman Chen [:chens] from comment #20)
> Danny and Ben, 
> 
> Could you both try this patch on 2.1 and share the result? 
> https://github.com/shamenchens/gaia/commit/
> 3b65ec4a955317502c7c0a7cb8eef5be343ea603
> 
> This patch tries to use SettingsCache to speedup system app bootup time,
> idea is borrowed from John who works on smart screen system bootup
> performance (bug 1090810). Ideally this could save 3+ secs.


Dear Sherman,

OK, I would do it tomorrow and tell you the result after verify.

Thanks.
Flags: needinfo?(ben.song)

    
    

    
  

      
      
      
      

        Attached file
          
        boot_log.tar.gz
        — 
      

    


  
Dear Vance,

This attachment is the boot log of v2.1 and v1.4 with new logs you apply.

Thanks
Flags: needinfo?(vchen)

    
    

    
  
hi Chens 

The new logs are available at Comment#22, please help to check if it has the information you need

Thanks

Vance
Flags: needinfo?(vchen)
Flags: needinfo?(dliang)
Flags: needinfo?(chens)

    
    

    
  
(In reply to Sherman Chen [:chens] from comment #20)
> Danny and Ben, 
> 
> Could you both try this patch on 2.1 and share the result? 
> https://github.com/shamenchens/gaia/commit/
> 3b65ec4a955317502c7c0a7cb8eef5be343ea603
> 
> This patch tries to use SettingsCache to speedup system app bootup time,
> idea is borrowed from John who works on smart screen system bootup
> performance (bug 1090810). Ideally this could save 3+ secs.

Dear Sherman,

I have applied this patch about SettingsCache in user-debug version, I find it could save 1.5~2 secs. For the patch is too big to conflict with some patch of sprd v2.1, so we haven't verify it on user version.

Thanks.

    
    

    
  
Hi Ben, 

I've made another patch for 2.1, should be easy for you to verify on your branch, you can try: https://github.com/shamenchens/gaia/commit/eba5bf5c24c7fd0ad7bc3be3dc1cb9c893be37d0

One more thing I would like to make sure, does that means no optimize was made when you build 'user-debug' version? If it's true, then you can save extra 1-2 secs if you turn optimize flag on.
Flags: needinfo?(chens) → needinfo?(ben.song)

    
    

    
  
(In reply to Sherman Chen [:chens] from comment #26)
> Hi Ben, 
> 
> I've made another patch for 2.1, should be easy for you to verify on your
> branch, you can try:
> https://github.com/shamenchens/gaia/commit/
> eba5bf5c24c7fd0ad7bc3be3dc1cb9c893be37d0
> 
> One more thing I would like to make sure, does that means no optimize was
> made when you build 'user-debug' version? If it's true, then you can save
> extra 1-2 secs if you turn optimize flag on.

Dear Sherman,

I mean after apply last patch we could save 1-2 secs, what is the optimize flag. I would try this patch and give you feedback tommorrom.

Thanks.
Flags: needinfo?(ben.song)

    
    

    
  
Ok, I found that your build didn't optimize js code, we can tell by this line:
> 07-22 08:07:28.850 E/GeckoConsole(  128): Content JS LOG at app://system.gaiamobile.org/js/bootstrap.js:226 in startup: [System] loadEnded

You can see the log is from `bootstrap.js`, which means you didn't pass `PRODUCTION=1` or `GAIA_OPTIMIZE=1` to build system and optimize js code. If you turn optimize flag on, then the log will be generated from `gaia_build_defer_index.js`. Our build system can aggregate separated js files into one and optimize it, so it can save more load time.

I would suggest you turn optimize flag on and you will have better result.

    
    

    
  
(In reply to Sherman Chen [:chens] from comment #28)
> Ok, I found that your build didn't optimize js code, we can tell by this
> line:
> > 07-22 08:07:28.850 E/GeckoConsole(  128): Content JS LOG at app://system.gaiamobile.org/js/bootstrap.js:226 in startup: [System] loadEnded
> 
> You can see the log is from `bootstrap.js`, which means you didn't pass
> `PRODUCTION=1` or `GAIA_OPTIMIZE=1` to build system and optimize js code. If
> you turn optimize flag on, then the log will be generated from
> `gaia_build_defer_index.js`. Our build system can aggregate separated js
> files into one and optimize it, so it can save more load time.
> 
> I would suggest you turn optimize flag on and you will have better result.

Dear Sherman,

I have verified the new patch and found it could save about 1~2 secs.

How to pass `PRODUCTION=1` or `GAIA_OPTIMIZE=1` to build system and optimize js code ?

Thanks.
Flags: needinfo?(chens)

    
    

    
  
Dear Sherman,

After apply this patch, I find some problem in screen of lockscreenWindow and settings app window. In the lockscreen this is a white block.

Thanks.

    
    

    
  
(In reply to ben.song from comment #29)
> How to pass `PRODUCTION=1` or `GAIA_OPTIMIZE=1` to build system and optimize
> js code ?
(In reply to ben.song from comment #30)
> After apply this patch, I find some problem in screen of lockscreenWindow
> and settings app window. In the lockscreen this is a white block.

If the second patch doesn't work for you, then you should go for the first patch approach.
Second patch change SettingsListener underlying mechanism to switch to SettingsCache once available, simple than the first one but is more risky. If there's some problem with it, I would suggest to change every SettingsListener usage to SettingsCache as the first patch does.

And from comment 29, it seems your code is not optimized, you can try `GAIA_OPTIMIZE=1 make`[1] when build gaia, Strongly suggest you try this first before heads down to change system app.

[1] https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/make_options_reference#JavaScript_optimization_make
Flags: needinfo?(chens)

    
    

    
  
Also ni Siiaceon -

Hi Ben, Siiaceon, as I remember, you test the performance with user debug, right? I am not sure if in user debug build you did turn on the compile option GAIA_OPTIMIZE. As Chens mentioned, it might help to improve the overall performance, would you help to check if the build you are testing with did turn on the GAIA_OPTIMIZE?

Thanks
Flags: needinfo?(siiaceon.cao)

    
    

    
  
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #32)
> Also ni Siiaceon -
> 
> Hi Ben, Siiaceon, as I remember, you test the performance with user debug,
> right? I am not sure if in user debug build you did turn on the compile
> option GAIA_OPTIMIZE. As Chens mentioned, it might help to improve the
> overall performance, would you help to check if the build you are testing
> with did turn on the GAIA_OPTIMIZE?
> 
> Thanks

Dear Vance,Sherman,

I would apply the second patch into user version and turn on the GAIA_OPTIMIZE.

Thanks.

    
    

    
  
Hi Ben, 

Seems you didn't get my comment, if second patch has some problem with you, then you should NOT apply the second patch. My suggestion is:
1. Turn on GAIA_OPTIMIZE 
2. Try to apply first patch and turn on GAIA_OPTIMIZE and see how it works
Flags: needinfo?(ben.song)

    
    

    
  
(In reply to Sherman Chen [:chens] from comment #34)
> Hi Ben, 
> 
> Seems you didn't get my comment, if second patch has some problem with you,
> then you should NOT apply the second patch. My suggestion is:
> 1. Turn on GAIA_OPTIMIZE 
> 2. Try to apply first patch and turn on GAIA_OPTIMIZE and see how it works

Dear Sherman,

OK. I would do it what you said.

Thanks.
Flags: needinfo?(siiaceon.cao)
Flags: needinfo?(ben.song)

    
    

    
  
Dear Sherman，

After apply first patch and make GAIA_OPTIMIZE be 1, the time of boot-strap save about 2-3 secs. But it still is more than lowest aim given by QA.

Now we still need continue to save 2-3s.

Thanks.
Flags: needinfo?(chens)

    
    

    
  
Hi Ben, 

Could you share us the latest test result? It would be helpful to know these two:
1. Boot up time with GAIA_OPTIMIZE, compare with Flame-v2.1 and 7715-v1.4
2. Boot up time with GAIA_OPTIMIZE and first patch, compare with Flame-v2.1 and 7715-v1.4
Flags: needinfo?(chens) → needinfo?(ben.song)

    
    

    
  
(In reply to Sherman Chen [:chens] from comment #37)
> Hi Ben, 
> 
> Could you share us the latest test result? It would be helpful to know these
> two:
> 1. Boot up time with GAIA_OPTIMIZE, compare with Flame-v2.1 and 7715-v1.4
> 2. Boot up time with GAIA_OPTIMIZE and first patch, compare with Flame-v2.1
> and 7715-v1.4

Dear Sherman,

1.boot up time with GAIA_OPTIMIZE, Flame-v2.1(CPU solo): 42.1s; 41.7s; 42.3s. 7715-v1.4: 37.6s; 37.1s; 36.9s.(user-debug version)

2.boot up time with GAIA_OPTIMIZE and first patch, Flame-v2.1(CPU solo): 40.7s; 40.8s; 41.1s. 7715-v1.4: 35.7s; 35.6s; 36.1s.(user-debug version)

3.boot up time with GAIA_OPTIMIZE and first patch, 7715-v1.4: 34.1s; 34.5s; 34.4s.(user version)

Thanks.
Flags: needinfo?(ben.song)

    
    

    
  
Hi Ben, 

Can you provide 7715-v2.1 result? by compare I mean to list the result of 7715-v2.1, Flame-v2.1 and 7715v1.4, so that we can see the difference after apply that patch/optimization, thanks.

    
    

    
  
Dear Sherman,

1.boot up time with GAIA_OPTIMIZE, Flame-v2.1(CPU solo): 42.1s; 41.7s; 42.3s. 7715-v2.1: 37.6s; 37.1s; 36.9s. 7715-v1.4: 33.8s; 33.7s; 33.8s.(user-debug version)

2.boot up time with GAIA_OPTIMIZE and first patch, Flame-v2.1(CPU solo): 40.7s; 40.8s; 41.1s. 7715-v2.1: 35.7s; 35.6s; 36.1s. 7715-v1.4: 32.8s; 33.1s; 32.6s(user-debug version)

Thanks.
Flags: needinfo?(chens)

    
    

    
  
May I know what's the benchmark from your QA? 

Another question, I didn't see the improvement (1-2 secs) you said compare with comment 1, are you sharing the correct test result? 
> 7715FFOSv2.1: 36.37/35.94/35.67 平均35.993
> FlameFFOSV2.1: 37.347/37.549/37.413 平均37.436
> 7715FFOSv1.4: 33.337/34.125/33.469 平均33.643
Flags: needinfo?(chens) → needinfo?(ben.song)

    
    

    
  
Dear Sherman,

Sorry for my no clear interpretation，for your first question, the benchmark of our QA is 7715FFOSv1.4, lowest aim is 33s, and highest aim is 27s.

Second, comment1 is from the test of user version, but comment40 is from the test of user-debug version, the latter is bigger than the former, and FlameFFOSV2.1 result of comment1 is from dual-core Flame machine.

Now, boot up time of user version with GAIA_OPTIMIZE and first patch, 7715-v2.1: 34.1s; 34.5s; 34.4s. It has saved 1-2s than modified and still need to save 2-3s.

Thanks.
Flags: needinfo?(ben.song) → needinfo?(chens)

        Attachment #8560350 -
        Attachment is obsolete: true
Flags: needinfo?(chens)

    
    

    
      
  


  

    
    

    
  
Comment on attachment 8562474 [details] [review]
WIP - SettingsCache

Hi Alive, how do you think if we change SettingsListener to SettingsCache to improve system launch time, could you give some feedback? 

The idea is to borrow SettingsCache from settings app, and try to retrieve all settings value and keep that in cache. I would like to know how you think about it, are we on the right direction? thanks!

        Attachment #8562474 -
        Flags: feedback? → feedback?(alive)

    
    

    
  
Comment on attachment 8562474 [details] [review]
WIP - SettingsCache

I am curious why caching will help because there shouldn't be too many observers using the same value, but if this works for 2.1 f+ for sure.

        Attachment #8562474 -
        Flags: feedback?(alive) → feedback+

    
  
Severity: normal → critical

    
  
Blocks: 1161387

    
  

          tracking-b2g:
          --- → -
OS: Linux → Gonk (Firefox OS)
Priority: -- → P4
Hardware: x86_64 → ARM

    
    

    
  
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 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: