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

Status: RESOLVED DUPLICATE of bug 992150

(Firefox OS Graveyard :: Gaia::Music, defect, P1)

Description

[Peipei Cheng (needinfo if you need my action)]

Attachment: 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

Comment 1

[Steven Yang [:styang]]

Hi Dominic, would you mind to take a look on this? thanks!

Comment 2

[Dominic Kuo [:dkuo]]

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.

Comment 3

[Peipei Cheng (needinfo if you need my action)]

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

Comment 4

[Dominic Kuo [:dkuo]]

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

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Is this really a bug (according to comment 2)?

Comment 6

[Hema Koka [:hema]]

Jim, can you help investigate

Comment 7

[Jim Porter (:squib)]

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

Comment 8

[Andreas Gal :gal]

Steven, if this is a first launch problem, why are we blocking on it?

Comment 9

[Dominic Kuo [:dkuo]]

Attachment: Music displays songs on tarako

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.

Comment 10

[Peipei Cheng (needinfo if you need my action)]

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.

Comment 11

[Peipei Cheng (needinfo if you need my action)]

After modifying all information (title/artist...) for all music to English, the performance is much better. 
depend on bug 997007

Comment 12

[James Zhang (Spreadtrum)]

Please remove chinese font on v1.3t, because tarako target market is not Chinese.

Comment 13

[Jim Porter (:squib)]

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

Comment 14

[Jim Porter (:squib)]

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

Comment 15

[Andreas Gal :gal]

Can we simply postpone font rendering until everything else is displayed?

Comment 16

[[:fabrice] Fabrice Desré]

If it's only a problem with Chinese characters, I think we need to unblock this bug for now.

Comment 17

[thomas tsai]

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.

Comment 18

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

triage: product decision to remove Chinese/Japanese/Korean font support.
to kli

Comment 19

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Should we just dup this bug to bug 992150 if the resolution is to remove the Chinese font here too?

Comment 20

[thomas tsai]

I think so after a verification of removing chinese fonts and compressed fonts. It's faster in my device after the removal.

Comment 21

[Kai-Zhen Li [:seinlin][:kli]]

Yes I think the root cause is the same as bug 992150.