[tarako][perf] improve the performance of music app loading songs

RESOLVED DUPLICATE of bug 992150

Status

defect
P1
normal
RESOLVED DUPLICATE of bug 992150
5 years ago
5 years ago

People

(Reporter: angelc04, Assigned: seinlin)

Tracking

({perf})

unspecified
1.4 S6 (25apr)
Other
Other
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.3T+, b2g-v1.3T affected)

Details

(Whiteboard: [c=progress p= s=2014.04.25 u=tarako][sprd297164] )

Attachments

(2 attachments)

Posted file Music.log
Steps to reproduce
--------------------------------------------------------------------
1. prepare some music (I have 16 in my test)
2. Launch Music
3. Switch to Songs list
   --> It took about 20s to load 16 songs. Artist list has similar problem.


Attached adb logcat. Tests starts: 04-16 18:33:58.170

Test build
----------------------------------------------------------------------
Gaia      c62bff0bfb8b069c962dfae2640e931cc9ad1bdf
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/7e764399b4fc
BuildID   20140415164003
Version   28.1
ro.build.version.incremental=eng.cltbld.20140415.201139
ro.build.date=Tue Apr 15 20:11:46 EDT 2014
blocking-b2g: --- → 1.3T?
Hi Dominic, would you mind to take a look on this? thanks!
blocking-b2g: 1.3T? → 1.3T+
Flags: needinfo?(dkuo)
Component: Performance → Gaia::Music
Keywords: perf
Priority: -- → P1
Whiteboard: [c=progress p= s= u=tarako]
I believe it's the first time launch of the music app? the first time scan takes time because we need to parse all the songs on sdcard then store the metadata in the indexedDB, after that, the second time launch should be fast and the scanning is in the background.
Flags: needinfo?(dkuo) → needinfo?(pcheng)
(In reply to Dominic Kuo [:dkuo] from comment #2)
> I believe it's the first time launch of the music app? the first time scan
> takes time because we need to parse all the songs on sdcard then store the
> metadata in the indexedDB, after that, the second time launch should be fast
> and the scanning is in the background.

This happens every time I kill Music app and relaunch. I didn't see much difference for the first launch. 
But on today's build, it took 6s to load 16 songs. That is better but user see an empty song list for about 6s before Song list appears. The user experience is still bad.
Flags: needinfo?(pcheng)
(In reply to pcheng from comment #3)
> (In reply to Dominic Kuo [:dkuo] from comment #2)
> > I believe it's the first time launch of the music app? the first time scan
> > takes time because we need to parse all the songs on sdcard then store the
> > metadata in the indexedDB, after that, the second time launch should be fast
> > and the scanning is in the background.
> 
> This happens every time I kill Music app and relaunch. I didn't see much
> difference for the first launch. 
> But on today's build, it took 6s to load 16 songs. That is better but user
> see an empty song list for about 6s before Song list appears. The user
> experience is still bad.

This sounds like we have some changes on the indexedDB because the loading time is changed with different builds.
Is this really a bug (according to comment 2)?
Jim, can you help investigate
Flags: needinfo?(squibblyflabbetydoo)
I can take a look. There's nothing that jumps out in the logcat though.

However, the numbers we have in this bug aren't especially useful. I'll try to reproduce this myself, but what we really need is an idea of how this scales to large numbers of songs. If it's a constant 6s, that's not great, but it's a lot better than something that scales as O(n) or O(n^2).
Flags: needinfo?(squibblyflabbetydoo)
Whiteboard: [c=progress p= s= u=tarako] → [c=progress p= s= u=tarako][sprd297164]
Steven, if this is a first launch problem, why are we blocking on it?
By using today's pvt build with about 80 songs on my sd card, I followed the steps in comment 0 and recorded a video, the response time looks okay for me, at least it's not 20 or 6 seconds, though I didn't really use a high speed camera or debug tools to measure it.

To be responsive, our strategy to display songs, artists or albums in list is to display the first 5 pages(about 7 * 5 records), that means even the user's collection got hundreds of songs, when the user try to view one of the lists, we only display the first 35 records, after the user scrolled the list, we will display the rest which depends the distance that the user scrolled. So the response time shouldn't be slow and should be consistent on displaying songs, artists and albums.
I still see this problem with my music files. But my music file has Chinese chracters, so I think it might be a side effect of packaging fonts in WOFF format. 

I will confirm this by changing file names to English only and update later.
Flags: needinfo?(pcheng)
After modifying all information (title/artist...) for all music to English, the performance is much better. 
depend on bug 997007
Depends on: 997007
Flags: needinfo?(pcheng)
Please remove chinese font on v1.3t, because tarako target market is not Chinese.
Flags: needinfo?(ttsai)
Flags: needinfo?(fabrice)
Whiteboard: [c=progress p= s= u=tarako][sprd297164] → [c=progress p= s= u=tarako][sprd297164] [partner-blocker]
(In reply to pcheng from comment #10)
> I still see this problem with my music files. But my music file has Chinese
> chracters, so I think it might be a side effect of packaging fonts in WOFF
> format. 

What encoding does your music use for ID3 data? Is it a form of UTF, or something like Big5 or GB? (If the artist/album info looks corrupted, it's probably Big5 or GB.) I'd be interested to know if the issue is because we're rendering the text really slowly or if we're choking on non-standard encodings in ID3. If the latter, we should probably start looking at bug 850520 (but only after I land bug 891024!).

(In reply to James Zhang from comment #12)
> Please remove chinese font on v1.3t, because tarako target market is not
> Chinese.

I think we should keep the font around; it doesn't seem to hurt things if the metadata uses Latin characters, and I'd rather us be slow-and-right than fast-and-wrong if the metadata uses Chinese characters.
(In reply to Jim Porter (:squib) from comment #13)
> If the latter, we should probably start looking at bug 850520...

Oops, I meant bug 841949.
Can we simply postpone font rendering until everything else is displayed?
If it's only a problem with Chinese characters, I think we need to unblock this bug for now.
Flags: needinfo?(fabrice)
Depends on: 992150
Flags: needinfo?(ttsai)
woff font and chinese font impact the performance and memory usage, so remove chinese fonts and .ttf fonts are used to minize the performance and memory impact, but the rom size needs to be estimated again.
triage: product decision to remove Chinese/Japanese/Korean font support.
to kli
Assignee: nobody → kli
Should we just dup this bug to bug 992150 if the resolution is to remove the Chinese font here too?
Status: NEW → ASSIGNED
Flags: needinfo?(kli)
Flags: needinfo?(jcheng)
I think so after a verification of removing chinese fonts and compressed fonts. It's faster in my device after the removal.
Yes I think the root cause is the same as bug 992150.
Flags: needinfo?(kli)
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(jcheng)
Resolution: --- → DUPLICATE
Duplicate of bug: 992150
Whiteboard: [c=progress p= s= u=tarako][sprd297164] [partner-blocker] → [c=progress p= s=2014.04.25 u=tarako][sprd297164] [partner-blocker]
Whiteboard: [c=progress p= s=2014.04.25 u=tarako][sprd297164] [partner-blocker] → [c=progress p= s=2014.04.25 u=tarako][sprd297164]
Target Milestone: --- → 1.4 S6 (25apr)
You need to log in before you can comment on or make changes to this bug.