817099 - [meta][Gaia::Cost Control] Long initial startup time for Cost Control app

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Cost Control, defect, P1)

Description

[Peter La]

What makes it feel slow/broken?
It takes too long to startup the Cost Control app after a reset.  Timed at 12.7 seconds on Unagi running Nov. 22 nightly.  David Clarke to provide more accurate, recent numbers.

Did it prevent you from doing what you wanted? Why?

How does this make you feel?

[ ]  :)  I feel happy about it
[ ]  :|  Meh
[X]  :(  I'm upset
[ ] >:O  I'm angry

Device: Original numbers from Unagi, Nov. 22 nightly.  David Clarke to get Otoro numbers.

Details:

B2G on Unagi:               12.7 seconds
Android ICS 4.0.4 on Otoro: No equivalent

David Clarke to provide updated B2G on Otoro numbers.

Bonus: can you attach a video of the problem?
See metabug 814981

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

BB+, P3 - performance. 12.7 seconds is too long

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

This bug seems like a meta bug and we don't block on meta bug. Someone need to investigate the reasons why it is slow and open blocking bugs that blocks this one.

Also the exact timing method should be described so the people that are going to work on it will be able to compare.

Renominating and triagers please explain why we block on a meta bug.

Comment 3

[David Scravaglieri [:scravag]]

Hey Gabriele, could you investigate to see what is slow please ?

Comment 4

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to dscravaglieri from comment #3)
> Hey Gabriele, could you investigate to see what is slow please ?

This app has a significant number of problems when being started the first time, here's the full profile:

http://people.mozilla.com/~bgirard/cleopatra/#report=2bdb4704f26944b64fdb0577738a102bdb405018

The overall measured startup time is ~6.5s, this includes a number of events that happen after the regular startup but that make the application unusable until they've finished. Here's the major problems:

- Localization functionality (l10n.js) is taking over 1s alone, this is a problem we experienced in other apps a lot in the past

- Page layout is taking over 1s too, to make matters worse it happens twice (you can see two major calls to layout::Flush). settings.html and the left-panel widget seem to blame for this.

- The _updateUI() call in data_usage.js is very slow, accounting for 0.7s in total over a few invocations. The shortest invocations are 120ms each while the longest is 290ms. It seems that this method is being called multiple times in response to changes in the preferences (onDataLimitValueChanged(), ccapp_onNextResetChanged() and ccapp_onLastResetValueChanged()) as well as after having received the sample data (cc_onMbileRequesSuccess()). It would be better if the changes were batched together and _updateUI() would be called only in the end in order to prevent the redundant calls.

Comment 5

[Salvador de la Puente González [:salva]]

The new implementation with no background service is focused on improve the performance of the entire application by reducing drastically the number of events being listened and trying to avoid as much repaint as possible.

Comment 6

[Salvador de la Puente González [:salva]]

Anyway I was trying and the time for first time startup is about 6s (I can not reproduce the 12s case) as Gabriele said.

The problem is the double load of First Time Experience (FTE) wizard and the application itself. I think this could be improved by hiding the load of the application and give all priority to the FTE but as I said in the former comment, I'm trying to remove the background service so the whole design will move to another "more adhoc" design and better in performance, I guess.

After the FTE, the startup time is about 2-3s, nothing more than dialer or SMS, for instance.

Comment 7

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 8

[Alex Keybl [:akeybl]]

This performance bug represents a non-trivial amount of work. Marking as a P1 issue to frontload risk.

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Can we block on specific bugs and not on [This APP is slow] fuzzy bug? This make it hard to really understand what work is ungoing and to split the work between people and between teams when it comes to front-end versus backend.

blocking-basecamp? but I believe this is a meta bug and should be bb-.

Comment 10

[Salvador de la Puente González [:salva]]

All dependencies are fixed. Closing.