One of the biggest problems in Homescreen startup performance is navigator.mozApps.mgmt's performance. This in itself is not an easily fixable problem, though some improvements are underway (bug 805293). Gaia will have to live with the fact that it usually takes a few (!) seconds to load app data via the DOM API. We must therefore change the Homescreen to start painting before this data is available. This essentially means caching all the data that's needed to paint in IndexedDB (which is an order of magnitude faster than mozApps) and then backfilling it with mozapps data later. Along with this change, we should make the Homescreen key apps not by origin but by manifestURL since that's the unique identifier for them. NB: This is a somewhat large change to the Homescreen codebase since it changes a bunch of assumptions that's made by the current implementation.

If that helps, I think we should rather return iterators and not arrays from functions like mozApps.mgmt.getAll()

(In reply to Fabrice Desré [:fabrice] from comment #1) > If that helps, I think we should rather return iterators and not arrays from > functions like mozApps.mgmt.getAll() This would help with other things, but not necessarily this particular problem.

This rewrites the bowels of the Homescreen app (persistency, state management, drawing, etc.) to draw as fast as possible. This means caching everything we need to draw the grid in IndexedDB, including the translated app name and icon (as blob, already rendered with drop shadow), and NOT waiting for slow APIs like mozApps. The storage model is simpler with bookmarks and mozApp icons in the same database, and the dock simply being the 1st grid page in the database. We also now use manifestURL (plus entry_point where applicable) as the key for apps instead of origin and handle entry_points correctly in all places now. With all of these changes, we start painting icons about 1.5 seconds sooner than before. Painting all icons takes less than 1.5 seconds now instead of 4-5 seconds before. Memory usage (USS and as reported by about:memory) drops by more than 1 meg.

Was pointing to the wrong pull request.

This may save over 200 KiB of memory consumption in the Homescreen; see bug 806383 comment 19 (and earlier comments for context).

Comment on attachment 678935 [details] pull request (correct one) r- because of the changes in init.json that will break DEBUG=1 and GAIA_DOMAIN. Also I would like to see a fix for the underlying but that crash the homescreen (which reload fast!) before landing that.

(In reply to Vivien Nicolas (:vingtetun) from comment #6) > Also I would like to see a fix for the underlying but that > crash the homescreen (which reload fast!) before landing that. Which crash are you referring to? the one we see only on desktop builds?

(In reply to Fabrice Desré [:fabrice] from comment #7) > (In reply to Vivien Nicolas (:vingtetun) from comment #6) > > > Also I would like to see a fix for the underlying but that > > crash the homescreen (which reload fast!) before landing that. > > Which crash are you referring to? the one we see only on desktop builds? Bug 809727.

Comment on attachment 678935 [details] pull request (correct one) I addressed your comments, Vivien, and a bunch of other bugs. There's still a few follow-up fixes that we should address (to avoid holding on to too much memory, to get updates right, and to improve the UX even further), but they shouldn't block this. I'll be filing them and starting work on them shortly.

Everything squashed into one big commit as requested in the pull request.

IMHO this new feature had a lot of risk and it had to be reviewed by me as well. For example, currently I've installed the master and I cannot uninstall apps (bookmarks are ok), I cannot add to homescreen apps from ev.me search (from wrappers works fine, ),... The idea is amazing, very hard work and I am very happy with it but we had to review with more detail

If this change is introducing so many new bugs I think it would be a good idea to back it out. If navigator.mozApps is slow it should be fixed but no the HS which has reached an stability status that it is worth keeping.

I don't know if there are several bugs or not. I only detected 3 bugs. The other bug is about not working the ev.me categories because of descriptor undefined. Although I am totally agree with Cantera