I have over 2000 tunes in the Music app. If I list all songs, or even all albums (much smaller list) or artists, and start scrolling down until you only have black, it takes a few second for the list to update and display. (this is a Flame)

I can reproduce this issue on OGA & NGA music app of FlameKK v2.5 latest build by STR in comment 0. Device: Flame KK v2.5(Affected) Build ID 20150921073455 Gaia Revision 2d370fa35c1a0ee2a637e3772c0843586a5f96c9 Gaia Date 2015-09-21 02:41:31 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/039a8490891595736b16a3ccb17f025f4dcf13eb Gecko Version 44.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150921.112037 Firmware Date Mon Sep 21 11:20:52 EDT 2015 Bootloader L1TC000118D0

Hub is going to test this case out on the NGA app. Ni'ing him.

I has different performance characteristics. For example if I tap on the "songs" tab, it take a few seconds to display more than an empty list. I have gaia 9a682cb7 on this Sony Z3C. From the OTA BuildID is 20151002103912

It might be worth checking to see how long the database query takes. If it's taking way too long, we'll (eventually) have to fix this by switching away from enumerateAll().

(In reply to Jim Porter (:squib) from comment #4) > It might be worth checking to see how long the database query takes. If it's > taking way too long, we'll (eventually) have to fix this by switching away > from enumerateAll(). Yes. This is probably an issue with either the time it takes to run the query or the time it takes to pass the results across the bridge. We should check both. If it is the query, we can probably break it up into two calls: one to get a summary listing of about 10-20 songs, the other to get the remainder. Longer term solution is to move away from MediaDB and take our architecture (and its limitations) into consideration when designing the replacement DB.

For the record, the performance is different, and scrolling down to the list is definitely faster than it used to be.

Github issue tracking new caching feature: https://github.com/gaia-components/gaia-fast-list/issues/4

This should be improved since bug 1214771 landed. The first view of a panel will take the same time, but once the list cache is primed, subsequent view should be very fast. One other way we can improve this is 'prerendering' the Artists, Albums and Songs panels on app launch. Although having all these panels rendered, will bump up memory usage. If QA are happy with the new perf let's close this, if not, let's open and block on a new 'add panel prerendering' bug.

(In reply to Wilson Page [:wilsonpage] from comment #9) > This should be improved since bug 1214771 landed. The first view of a panel > will take the same time, but once the list cache is primed, subsequent view > should be very fast. > > One other way we can improve this is 'prerendering' the Artists, Albums and > Songs panels on app launch. Although having all these panels rendered, will > bump up memory usage. > > If QA are happy with the new perf let's close this, if not, let's open and > block on a new 'add panel prerendering' bug. Yes, pre-rendering is definitely the way forward with this and this is a technique that was proposed via NGA using markup to specify which views should be pre-rendered in the background. However, it is too late to do it for v2.5 as it may introduce performance regressions (especially memory).

Firefox OS is not being worked on