796467 - Startup time for Calendar app is high (~4-5sec)

Status: RESOLVED INVALID

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

Description

[GH to BZ]

[GitHub issue by cgjones on 2012-08-09T17:28:11Z, https://github.com/mozilla-b2g/gaia/issues/3306]
For OOP apps, we currently have about 700ms of fat to cut: 500ms from the app-load animation, and then ~200ms coming from a platform fix.  However, if you load Calculator and compare to Calendar, Calendar is ~1.5-2s slower to start up.  We should look for low-hanging fruit here, ideally with a profiler.

@fabricedesre @mounirlamouri how do we load the app .zip currently?  Are requests for all resources forwarded to the master process, or do we send the .zip to subprocesses once and load directly from there afterwards?

@glandium do you know of any in-tree tools we can use to profile app startup?  Something that can gather data like network console / bootchart.  Pretty UI optional :).

Comment 1

[GH to BZ]

[GitHub comment by cgjones on 2012-08-09T17:28:49Z]
CC @lightsofapollo

Comment 2

[GH to BZ]

[GitHub comment by fabricedesre on 2012-08-09T17:43:23Z]
@cgjones zipped apps are loaded by the jar channel implementation. I think everything just runs in the child.

Comment 3

[GH to BZ]

[GitHub comment by nhirata on 2012-08-09T18:49:16Z]
@cgjones, I think this bug applies to all applications that load for the first time.

Can you compare by verifying this?  you can kill an app by long tapping on home and then pulling the mini image of the app upwards and retesting.  (you don't have to reboot the device each time)

If that is the case, we may want to change your title.

Comment 4

[GH to BZ]

[GitHub comment by lightsofapollo on 2012-08-09T22:29:11Z]
Calendar loads a *ton* of files some of them quite large.

For production I plan to have a build step to merge all files needed for
initial load
into a single file in addition some the larger files are only needed when
syncing and
will be run in a worker when I can do the systemXHR there.

Its not quite time to optimize the in app part of this but I think we can
benefit from similar techniques
in most apps.

On Thu, Aug 9, 2012 at 11:49 AM, nhirata <[e-mail]> wrote:

> @cgjones <https://github.com/cgjones>, I think this bug applies to all
> applications that load for the first time.
>
> Can you compare by verifying this? you can kill an app by long tapping on
> home and then pulling the mini image of the app upwards and retesting. (you
> don't have to reboot the device each time)
>
> If that is the case, we may want to change your title.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/mozilla-b2g/gaia/issues/3306#issuecomment-7623221>.
>
>

Comment 5

[GH to BZ]

[GitHub comment by cgjones on 2012-08-10T05:45:39Z]
Are all those files loaded on startup really needed, or can they be lazily loaded?

Remember, the target is to get ~meaningful pixels onto screen as quickly as possible, and *then* full functionality asap.  It's better even to hurt absolute throughput in the service of user-perceived responsiveness.  We do that all over the place.

Comment 6

[GH to BZ]

[GitHub comment by glandium on 2012-08-10T06:17:16Z]
Unfortunately, for child process startup, there's not so much available at the moment. You can however cheat with a bootchart-enabled init (build.sh INIT_BOOTCHART=true), and put a long timeout in /data/bootchart-start (however note there's a hardcoded max of 10 minutes). It should be pretty trivial to modify init (system/core/init/{init,bootchart}.c) to start/stop bootchart on a signal.

Comment 7

[GH to BZ]

[GitHub comment by glandium on 2012-08-10T06:18:35Z]
In fact, it should be possible to take bootchart.c out of system/core/init, and use it in a standalone program.

Comment 8

[GH to BZ]

[GitHub comment by lightsofapollo on 2012-08-10T06:23:58Z]
as I mention above we can move a many (30-50% of actual lines of code) to synchronization worker once we can do the xhr from there. Loading that worker can be deferred until the first sync which I expect to make a big difference on load times.

 There are a few more files we can lazy load (like the views which are already lazily rendered).

Comment 9

[GH to BZ]

[GitHub comment by cgjones on 2012-08-10T06:41:18Z]
Great --- i read up to "For production I plan to have a build step to merge all files needed for initial load into a single file" and then responded ;).  That sounds like a good approach.

We should definitely do this work based on the results of tooling instead of grasping at straws.  We'll want the approach to generalize to everywhere else.

Comment 10

[GH to BZ]

[GitHub comment by glandium on 2012-08-10T08:18:00Z]
Standalone bootchart here:
https://github.com/glandium/android-bootchart

Just clone somewhere under the B2G top directory, build with ./build.sh bootchart, and copy out/target/product/*/system/bin/bootchart on your device. Run the binary when you want to start charting, do your stuff, and ctrl-c when you're done. Then use the grab-bootchart.sh script to get the data, and draw the chart with bootchart from http://www.bootchart.org/. Note I/O is not properly tracked, but I/O wait is.

Ideally, it would be better to use
https://github.com/mmeeks/bootchart
but while I dot it building, it doesn't work yet, because it's designed for desktop paths.

Comment 11

[GH to BZ]

[GitHub comment by cgjones on 2012-08-11T22:40:39Z]
Very useful, thanks!

http://people.mozilla.com/~cjones/calendar.svg

If the data are reliable, then the content process (the name of which is overflowing the display :/), is spending all its time chewing CPU.  So we're doing fine with reading resources from the app package.  Just need to defer more parse+execute.

Comment 12

[GH to BZ]

[GitHub comment by cgjones on 2012-08-11T22:55:14Z]
Actually looked at the code for the first time ... oh my we're loading a lot! :)

Let's use this as an exemplar for improving load perf.  Let's do this sooner rather than later.

Need to think about the approach ...

Comment 13

[GH to BZ]

[GitHub comment by autonome on 2012-08-22T15:31:03Z]
Blocking. @cgjones should this be assigned to you to track the platform fixes you refer to in comment #0?

@lightsofapollo can you file a separate bug for the calendar-specific fixes?

Comment 14

[GH to BZ]

[GitHub comment by cgjones on 2012-08-22T18:13:50Z]
> Blocking. @cgjones should this be assigned to you to track the platform fixes you refer to in comment #0?

No, with the platform fixes starting up a "null app" is instantaneous by user perception.  (One patch left to land.)  All the overhead here is from the calendar app itself.

Comment 15

[GH to BZ]

[GitHub comment by cgjones on 2012-09-13T23:28:08Z]
I don't think optimizing startup of just the calendar is LOE:L, but using it as a testcase to create reusable tools is more work.

Comment 16

[Chris Lee [:clee]]

Should we expand this bug to all apps vs. just Calendar?

Comment 17

[Andreas Gal :gal]

One bug per app. A lot of the problems are per-app. We don't need a lot of tooling here for some initial progress. Just from looking at the structure of the app and whats being loaded during the initial load its obvious how to massively reduce load time.

Comment 18

[James Lal [:lightsofapollo]]

Moving out of calendar component. I will file separate bugs for the individual pieces of this.

Comment 19

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The gaia side of slim-fast is now in the capable hands of philikon.  Phil, please feel free to reassign as you see fit.

Comment 20

[Alex Keybl [:akeybl]]

We're marking this bug with the C1 milestone since it follows the criteria of "remaining LOE:L work" (see https://etherpad.mozilla.org/b2g-convergence-schedule).

If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.

Comment 21

[Alex Keybl [:akeybl]]

Upon further review, it's not clear that this bug specifically represents anything actionable. No longer need this to be blocking.

Comment 24

[David Scravaglieri [:scravag]]

This is a meta bug not actionnable

Comment 25

[James Lal [:lightsofapollo]]

Going to close this one... we have more perf work to do but we can open a new bug to do it in.