Closed
Bug 917620
Opened 12 years ago
Closed 12 years ago
[1.2] Music App launch time has regressed (compared to [1.1])
Categories
(Firefox OS Graveyard :: Gaia::Music, defect, P1)
Tracking
(blocking-b2g:koi+, b2g-v1.2 wontfix)
Tracking | Status | |
---|---|---|
b2g-v1.2 | --- | wontfix |
People
(Reporter: mvikram, Assigned: huseby)
References
Details
(Keywords: perf, regression, Whiteboard: [c=progress p= s= u=1.2] )
Attachments
(1 file, 1 obsolete file)
7 bytes,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
Steps to reproduce:
Launch the Music App (QRD 7x27 device). Measurements are made using a high speed camera measuring the time from when the touch event was recognized to first app paint.
Actual results:
Measured time on (1.2) is:
3329 ms
Measured time on (1.1):
2148 ms
Expected results:
Would expect launch time to be close to 1.1 or better.
Reporter | ||
Updated•12 years ago
|
Updated•12 years ago
|
Component: General → Gaia::Music
Keywords: perf,
regression
Updated•12 years ago
|
blocking-b2g: koi? → koi+
Whiteboard: [c=progress p= s= u=]
Updated•12 years ago
|
Whiteboard: [c=progress p= s= u=] → [c=progress p= s= u=1.2]
Comment 1•12 years ago
|
||
Per Sandip on bug 914911: First time launch latency for Music app is 2200ms.
Updated•12 years ago
|
Assignee: nobody → dhuseby
Updated•12 years ago
|
Target Milestone: --- → 1.2 C3(Oct25)
Assignee | ||
Updated•12 years ago
|
Whiteboard: [c=progress p= s= u=1.2] → [c=progress p=4 s= u=1.2]
Reporter | ||
Comment 3•12 years ago
|
||
Music app has shown regression in two builds taken approximately a week apart.
Latency: 2317 (ms)
Gaia version:
313599c293f596519604070fa378ffc89e61e98f
Gecko version:
bd1bd2486c85e449244de79dd80e10040397d3cf
Latency: 1958 (ms)
Gaia version:
5e0d0df6a762cf1e1812eeb735fba72e2539dc0c
Gecko version:
b318b86aeb90a517f183abecd6b45c99065eb473
Comment 4•12 years ago
|
||
Hema Koka deleted the linked story in Pivotal Tracker
Comment 5•12 years ago
|
||
(In reply to Mandyam Vikram from comment #3)
> Music app has shown regression in two builds taken approximately a week
> apart.
> ...
Dave Huseby is actively working this issue.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 6•12 years ago
|
||
Attachment #822445 -
Flags: review?(dkuo)
Attachment #822445 -
Flags: feedback?(kgrandon)
Comment 7•12 years ago
|
||
Comment on attachment 822445 [details] [review]
This shaves 100ms off of the Music app startup time.
Disclaimer: I haven't looked too deeply into the music code, so I don't know if this would cause any adverse issues.
This generally looks good to me. If we don't need to do this for rendering the page, I would say that we could probably shave off some additional time by calling LazyLoader.load on the communications.js file before calling init().
Attachment #822445 -
Flags: feedback?(kgrandon) → feedback+
Comment 8•12 years ago
|
||
Dave, thanks for working on this, to be clear and make sure we are on the same track, would you please tell me how you measure the startup time?
Last time when I was tuning the startup time, I used the develop menu in the settings app:
Device information > More information > Developer > Show time to load
to log the startup time.
Flags: needinfo?(dhuseby)
Assignee | ||
Comment 9•12 years ago
|
||
I'm using the profiler and profile builds of b2g. The only sure way to measure the times is with a high speed camera and eideticker setup. I'm doing the best I can with the profiler. I profile the b2g compositor thread and the pre-allocated process, then launch the music app, and then grab the profile dump after the music app has finished loading.
There are a couple of profile dumps here:
https://people.mozilla.org/~bgirard/cleopatra/#report=f57ecb0409d85635334e892af5f0ed29657a5713
I noticed that the the comms stuff was in the middle of the musicdb scan. Since the UI can't be fully drawn until the musicdb scan is finished, I thought to move the comms stuff until after the musicdb scan. The profiles consistently show the comms init at 100ms so by moving this to after the musicdb scan, we effectively shave off 100ms from the launch to the time the UI is fully drawn.
Flags: needinfo?(dhuseby)
Assignee | ||
Comment 10•12 years ago
|
||
What music files were stored on the device when you launched the Music app? Were they stored in the device flash or on an SD card?
Flags: needinfo?(mvikram)
Reporter | ||
Comment 11•12 years ago
|
||
As measured on the following build, the launch time (2021 ms) is on par with 1.1:
Gaia version:
845801e0c74badf0b96657a864935ef1a983cf47
Gecko version:
bbb4c0a8fa65cf1546a6cedc4c20fea16cd63ef2
As a result, I'm changing it to not be a blocker for 1.2, while this attachment can still be pursued further. To be risk averse, maybe this should go to 1.3
Reporter | ||
Updated•12 years ago
|
Flags: needinfo?(mvikram)
Assignee | ||
Comment 12•12 years ago
|
||
Can you still please give me details on the test you ran? What music files did you have on the device and were they stored on the built-in flash or on an SD card?
Thanks!
Flags: needinfo?(mvikram)
Assignee | ||
Comment 13•12 years ago
|
||
I'm closing this since it no longer blocks 1.2. However, the improvements patch hasn't landed yet so I started bug 932388 to track the Music app launch improvements.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: needinfo?(mvikram)
Resolution: --- → FIXED
Comment 14•12 years ago
|
||
(In reply to Dave Huseby [:huseby] from comment #13)
> I'm closing this since it no longer blocks 1.2. However, the improvements
> patch hasn't landed yet so I started bug 932388 to track the Music app
> launch improvements.
Should we remove koi+ then?
Comment 15•12 years ago
|
||
Dave,
Please obsolete the attached patch and add it to bug 932388 instead.
Whiteboard: [c=progress p=4 s= u=1.2] → [c=progress p= s= u=1.2]
Assignee | ||
Comment 16•12 years ago
|
||
Obsoleting patch moving to bug 932388
Attachment #822445 -
Attachment is obsolete: true
Attachment #822445 -
Flags: review?(dkuo)
Comment 17•12 years ago
|
||
Setting Target Milestone for this sprint's koi+ fixes.
Target Milestone: 1.2 C3(Oct25) → 1.2 C4(Nov8)
Updated•11 years ago
|
status-b2g-v1.2:
--- → wontfix
You need to log in
before you can comment on or make changes to this bug.
Description
•