Closed Bug 1031572 Opened 10 years ago Closed 10 years ago

FxOS: Settings App Launch Time Regression

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX
2.0 S5 (4july)

People

(Reporter: mlee, Assigned: Eli)

References

()

Details

(Keywords: perf, regression, Whiteboard: [c=regression p=2 s= u=])

Attachments

(2 files)

See attached screenshot of and linked Datazilla graph showing ~500 ms regression in launch time from 2014.06.24

Median Visually Complete Launch Times:

2014.06.24: 2878
2014.06.27: 3390
blocking-b2g: --- → 2.1?
Unfortunately the new startup tests aren't very accurate because our current low number of iterations (bug 1025079) and make test-perf errors (bug 1020557). Once these are resolved we can begin to use the new startup tests to look for regressions.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
blocking-b2g: 2.1? → ---
I am actually going to try and replicate these results locally to overcome the low iterations and hopefully avoid any make test-perf errors and will report back my findings.
Assignee: nobody → eperelman
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Whiteboard: [c=startup p= s= u=] → [c=startup p=2 s= u=]
Status: REOPENED → ASSIGNED
Attachment #8448132 - Attachment mime type: text/plain → text/html
Gaia 7f92040
Gecko 26b32c9

{
      "title": "startup > moz-app-visually-complete",
      "fullTitle": "startup event test > settings > startup > moz-app-visually-complete",
      "duration": 414108,
      "mozPerfDurations": [
        2772.9251029999996,
        2792.4952080000003,
        2745.7102079999995,
        2673.745259999999,
        2757.4057810000004,
        2648.2588530000003,
        2636.5003110000016,
        2701.3129179999996,
        2738.1183329999985,
        2723.122497999999,
        2710.4983329999986,
        2795.589322,
        2664.0474999999997,
        2673.529584,
        2763.973229,
        2740.074633999998,
        2710.602602,
        2728.480103000001,
        2689.0576029999993,
        2749.0924989999994,
        2608.531353000001,
        2773.578176,
        2746.186093000001,
        2691.361092,
        2773.720155,
        2611.5098430000007,
        2679.8148949999995,
        2675.3056240000005,
        2711.264843000001,
        2822.736562
      ],
      "mozPerfDurationsAverage": 2716.951617266667
}
Gaia decffed
Gecko 57d6c56

{
      "title": "startup > moz-app-visually-complete",
      "fullTitle": "startup event test > settings > startup > moz-app-visually-complete",
      "duration": 408546,
      "mozPerfDurations": [
        3276.8278629999986,
        3217.807759000001,
        3241.8677069999994,
        3264.511977000001,
        3263.4067689999993,
        3292.899114,
        3367.7080190000015,
        3240.5080719999996,
        3187.8803629999993,
        3244.8263529999995,
        3209.976924999999,
        3252.970362,
        3235.282290000001,
        3205.9617180000023,
        3302.9221339999995,
        3406.245207,
        3372.0029669999994,
        3217.432135,
        3318.6249470000002,
        3343.761872,
        3359.216926000001,
        3260.0519780000013,
        3422.559737999999,
        3458.2619779999986,
        3460.162446999999,
        3205.122343,
        3289.949009,
        3256.3205720000014,
        3347.3146880000013,
        3386.076144999999
      ],
      "mozPerfDurationsAverage": 3296.948679233333
}
I mistakenly came to the wrong conclusion when looking at Mike's data, so I apologize for that. According to Datazilla, and sure enough by my own testing, I clearly show a startup regression in the Settings application. The jump in moz-app-visually-complete goes from an average of 2717ms to 3297ms; a difference of 580ms locally on my Flame.
git bisect start decffed 7f92040
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[5f2c61ae3bbdad0c46c2ef5c808182a099e429c9] Merge pull request #20901 from etiennesegonzac/bug-1028002

---

make test-perf moz-app-visually-complete average: 3219.1974881999995

git bisect bad
Bisecting: 1 revision left to test after this (roughly 1 step)
[2cba65f24e53b56a359137c6145e23c0790eb8a6] Merge pull request #20882 from crdlc/bug-1028841

---

make test-perf moz-app-visually-complete average: 2763.6488532

git bisect good
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e9aaefa6c4e5aa7522ba6df44924dfdbb383c903] Bug 1028002 - Make sure an appWindow is in 'opened' state once we got the animationend and mozbrowserloadened instead of waiting for the opening timeout.

---

make test-perf moz-app-visually-complete average: 3256.7665398

git bisect bad

e9aaefa6c4e5aa7522ba6df44924dfdbb383c903 is the first bad commit
commit e9aaefa6c4e5aa7522ba6df44924dfdbb383c903
Author: Etienne Segonzac <etienne@segonzac.info>
Date:   Mon Jun 23 18:42:44 2014 +0200

    Bug 1028002 - Make sure an appWindow is in 'opened' state once we got the animationend and mozbrowserloadened instead of waiting for the opening timeout.

:040000 040000 ae77aeafbcbd0ce7d0782cd5e47bbd19da622203 0fa3de2c82ca8397a639e856b8e4df4977a25b44 M	apps
Etienne, do you have any information on whether this issue is easily resolvable or should be backed out? It is causing a 580ms regression in making the launch of the Settings app.
Flags: needinfo?(etienne)
We make sure apps don't get touch events during the opening transition.
There was a bug and before this patch the app was considered "in transition" and not getting touch events during 2.5sec regardless of the launch time.

No app could process input from the user before 2.5 seconds on cold launch.

Now on cold launch we wait for the transition to be over _and_ the app to be loaded (mozbrowserloadend) then the opening sequence is considered over and the app can process events.
As a user this was a big performance improvement.

I'm open to suggestions but I'd argue those new measurements are just closer to the reality of using the phone.
Flags: needinfo?(etienne)
Whiteboard: [c=startup p=2 s= u=] → [c=regression p=2 s= u=]
Blocks: 1028002
blocking-b2g: --- → 2.0?
Component: Gaia::Settings → Gaia::System::Window Mgmt
Going to hold off the nom until this is confirmed to be a problem in Gaia, rather than the measurement methodology.
blocking-b2g: 2.0? → ---
After having a discussion with Etienne, it appears that this is a side effect of some optimizations with the WindowManager and how it displays applications and allows events to be triggered. The numbers being reported are now more realistic to when event triggering actually occurs, and this has the potential to affect several applications.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → WONTFIX
Target Milestone: --- → 2.0 S5 (4july)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: