817113 - [meta][Gaia::Gallery] Long initial startup time for Gallery app

Status: RESOLVED FIXED

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

Description

[Peter La]

What makes it feel slow/broken?
It takes too long to startup the Gallery app after a reset.  Timed at 4 seconds on Unagi running Nov. 22 nightly.  David Clarke to provide more accurate, recent numbers.

Did it prevent you from doing what you wanted? Why?

How does this make you feel?

[ ]  :)  I feel happy about it
[ ]  :|  Meh
[X]  :(  I'm upset
[ ] >:O  I'm angry

Device: Original numbers from Unagi, Nov. 22 nightly.  David Clarke to get Otoro numbers.

Details:

B2G on Unagi:               4 seconds
Android ICS 4.0.4 on Otoro: 1.7 seconds

David Clarke to provide updated B2G on Otoro numbers.

Bonus: can you attach a video of the problem?
See metabug 814981

Comment 1

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

This bug seems like a meta bug and we don't block on meta bug. Someone need to investigate the reasons why it is slow and open blocking bugs that blocks this one.

Also the exact timing method should be described so the people that are going to work on it will be able to compare.

Renominating and triagers please explain why we block on a meta bug.

Comment 2

[David Scravaglieri [:scravag]]

Hey Gabriele, could you investigate to see what is slow please ?

Comment 3

[Gabriele Svelto [:gsvelto]]

This is a profile of the gallery app starting up, I've taken it without any pictures in the /sdcard/DCIM folder to focus on the startup time of the app itself:

http://people.mozilla.com/~bgirard/cleopatra/#report=f53476a0d1d9294e44b522ff58af6c66de0c6eae

The measured startup time is 2s even though it appears longer when doing a stop-watch measurement. Looking at the profile there's not much to save. The application JavaScript code itself is taking fairly little time to execute and most of it (~100ms) is in mediadb.js in response to I/O.

l10n.js is still taking a pretty large chunk of the startup time at 170ms (as usual divided among a zillion different calls) and another 100ms are spent in various calls to contentSecurityPolicy.js. Apart from this there aren't many others significant hot-spots.

I'll do another profile run but this time with the /sdcard/DCIM directory populated to estimate the impact of generating the picture thumbnails and displaying them.

Comment 4

[Gabriele Svelto [:gsvelto]]

This is a profiled run with 52 images in the DCIM directory (including mostly the example ones plus a few pictures I've taken):

http://people.mozilla.com/~bgirard/cleopatra/#report=ffd41e80d4628ebda93da9fba8f3b5487b697796

Startup time has grown to 6 seconds even though there's ~500ms worth of idle time due to I/O.

mediadb.js now accounts for 500ms, this time is mostly spent while enumerating the pictures and it seems caused by the underlying activities rather than the script itself so I wouldn't worry too much about it.

The other very large timesink however is laying out and repainting the screen, over 2400ms are spent on it. It looks like every time a picture is enumerated it triggers a layout -> repaint cycle which is quite expensive. It might be worth finding a more efficient way of doing it to reduce its impact.

Comment 5

[David Flanagan [:djf]]

(In reply to Gabriele Svelto [:gsvelto] from comment #4)
 
> The other very large timesink however is laying out and repainting the
> screen, over 2400ms are spent on it. It looks like every time a picture is
> enumerated it triggers a layout -> repaint cycle which is quite expensive.
> It might be worth finding a more efficient way of doing it to reduce its
> impact.

Fixing 808470 should help with this.

819182 is also a startup performance bug, but more specifically focused on the time it takes for a just-taken photo to show up.

Gabriele: how are you determining when the gallery has started?  Once 808470 is fixed, the gallery should be usable even while a scan is still in progress.  You'll see the crawling ants animation, but you should be able to use it while it scans for new photos.

Comment 6

[Gabriele Svelto [:gsvelto]]

(In reply to David Flanagan [:djf] from comment #5)
> Fixing 808470 should help with this.
> 
> 819182 is also a startup performance bug, but more specifically focused on
> the time it takes for a just-taken photo to show up.

Yes, both bugs look like they'd greatly improve the startup performance.

> Gabriele: how are you determining when the gallery has started?

In the link I posted in comment 4 if you click on the left-most part of the graph you'll highlight in green the time spent waiting for input. The rest will be the time the application is active so the right-most black bars will be the beginning of the actual startup activity. By clicking on the various part of this activity you should be able to identify the various stages of startup as well as the scanning part (which can be seen as a series of layout/paint operations).

The original trace was much longer and I clipped it for ease of use; if you capture a profile yourself you can use the same technique to get an accurate measurement of the startup time and related activities.

Comment 7

[Alex Keybl [:akeybl]]

This performance bug represents a non-trivial amount of work. Marking as a P1 issue to frontload risk.

Comment 8

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Can we block on specific bugs and not on [This APP is slow] fuzzy bug? This make it hard to really understand what work is ungoing and to split the work between people and between teams when it comes to front-end versus backend.

blocking-basecamp? but I believe this is a meta bug and should be bb-.

Comment 9

[David Scravaglieri [:scravag]]

Set as meta blocked by dependents

Comment 10

[Leo]

Marking tef? as its tricky to follow-up all dependent defects.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

As mentioned in comment 8, we need to block the specific bugs that are preventing the ship of v1.0, not the meta bug.

Comment 12

[David Flanagan [:djf]]

Adding bug 834957 to the dependencies list.  The fix to that bug optimizes the mediadb logic for the first scan and reduces the time until we have twelve thumbnails on the screen substantially.

Comment 13

[David Flanagan [:djf]]

Adding bug 836109 to the dependencies list. The patch in that bug makes a tiny (but measurable) improvement to the speed of extracting the preview image from a JPEG file.

Comment 14

[David Flanagan [:djf]]

Bug 838219 and bug 838223 are both specific performance improvements I'd like to make to gallery.

Comment 15

[David Flanagan [:djf]]

Bug 838223 has a patch under review. It makes a substantial improvement in startup time.  Bug 838219 is proving too risky to fix for 1.0, so it has been postponed to 1.1

Comment 16

[David Flanagan [:djf]]

Bug 838219 is an idea I'd like to experiment with, but that is a long-term goal, not an immediate blocker.  I'm satisfied with the gallery performance gains acheived with other bugs, and am not actually convinced that replacing mediadb (in bug 838219) would actually speed things up.  

So unless anyone objects, I'd like to close this bug as resolved/fixed.

Comment 17

[David Flanagan [:djf]]

Closing. Leo will file a specific gallery startup perf bug.