What makes it feel slow/broken? It takes too long to startup the Settings app after a reset. Currently ~4 seconds, or more. 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 [ ] :( I'm upset [ ] >:O I'm angry Device: (Otoro/Unagi/Samsung Galaxy, etc) Details: (technical factors, FPS, app startup time, ms elapsed, etc) Bonus: can you attach a video of the problem? See metabug 814981

Additional info: Comparable - Android ICS 4.0.4 on Otoro - .5 seconds cold launch for Settings. David Clarke to provide our current numbers for B2G on Otoro.

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.

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

@vingtetun - See bottom of comments section on Bug 814981 for timing method used.

Here's a full profile trace of the settings app starting up, the total measured startup time was 3.7s: http://people.mozilla.com/~bgirard/cleopatra/#report=757539543c3427b7c5f8f104ae13490260223c11 The time spent starting the app is divided among many small tasks but there are still two very large hot spots. The largest timesink is repainting, it seems to take ~900ms in one go after the page has been laid out. This seems triggered after layout for index.html#root has finished though I'm not 100% sure as it's not easy to tell from the profile. It is also unclear to me why painting the root panel would take so long, repainting it is a pretty cheap operation later on so something might be amiss the first time it happens. The second other major timesink is l10n.js which seems to be taking ~400ms. This is a known problem and it's been tackled in bug 809600.

Were you testing in a build with bug 815381 fixed?

(In reply to Chris Jones [:cjones] [:warhammer] from comment #6) > Were you testing in a build with bug 815381 fixed? Yes, I had synched the code this morning and the fix for that bug was among the commits. I could notice the difference already because before you could literally see the first panel sliding in when you opened the app and now it doesn't happen anymore.

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

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-.

Considering this as meta

Please see Chris's commment here: bug 817051 comment 14. Can UX help by providing more detailed targets, perhaps? Just let us know.

Need more investigations on this.

The startup time has been vastly improved on the Settings app during the last 2-3 months. The two majors improvements are: • sub-panel lazy loading, implemented during the SF work week • l10n inlining: pre-translation + pre-parsed dictionary, see bug 815852 But there has been a recent regression regarding this startup time — see bug 830545. As Vivien noticed, this might be caused by the fact that the first panel shows up with a transition. Investigating.

With the fix in bug 808216 we're down to ~1.9 cold startup. With the in-flight work in bug 834622, we'll knock several 100ms more off that. So we can probably expect to get down to ~1.5s with generic platform improvements. djf, do you have a bug on file for your eager fake-settings-lock idea? If so, can you set it to block here? jlal, have you tried combine+minify CSS on the settings app? Any improvements?

Kaze, what other changes need to happen here? There's one open blocker, but it is not specific to any plan for improvement.

We’re below 1000 ms now (in optimized mode), mostly thanks to the many general improvements that Vivien & al recently did. We could still will a few ms by lazy-loading the `l10n_date.js' library, see bug 849184.

Settings still takes 1.5s to launch on v1-train [1] so I'm wondering if we haven't missed a bunch of uplifts. [1] https://datazilla.mozilla.org/b2g?branch=v1-train&range=7&test=cold_load_time&app=settings&app_list=settings&gaia_rev=62300c323daf64ac&gecko_rev=e14b1ae8bcb8205a

Kaze, can you take a look? Do you know if we're missing a bunch of uplifts?

I can have a look at this next week if it’s OK with my manager (David, ping?). Otherwise, Anthony should be able to help.

With the link I gave in comment 17, Settings on v1-train is now under 1s (which is actually faster than Settings on master). So I guess those uplifts happened and we can close this bug.