Closed Bug 1210849 Opened 6 years ago Closed 6 years ago
Camera startup time and memory profile have regressed since 2
From the discussion at https://groups.google.com/forum/#!topic/mozilla.dev.fxos/HeGci2jormU : Camera v2.2 cold launch: 1492ms Camera current cold launch: 2090ms (~600ms regression) Camera v2.2 USS: 13.83MB Camera current USS: 16.05MB (~2.2MB regression)
Assignee: nobody → aosmond
[Blocking Requested - why for this release]: Regression of 600ms is huge, needs to be quantified and ideally eliminated or reduced.
Status: NEW → ASSIGNED
blocking-b2g: --- → 2.5?
Bug 1176191 effectively changed the startup behaviour such that it would not request the camera until we had localized -- this was because it wanted to know the low battery status first (i.e. we don't want to load it if in shutdown) but the battery controller did not set the status until it was localized. Bug 1196177 changes this to set the status as soon as we know it (e.g. on startup), even if it has to wait to display a notification (e.g. in low battery cases), which matches the original behaviour in the normal case. As such, the loading of the camera now depends on when the visibility changes for the app comes in. This is an area that should be investigated because when cold launching, because we know the visibility event is coming and the camera loading is async off the main thread.
Depends on: 1196177
Querying the settings API is (relatively) expensive and we do this on each launch to check if it is running on a nexus 4. The hardware zoom is somewhat broken on nexus 4 and uses a workaround if detected. The proper place to fix this is in Gecko, and if necessary export a maximum hardware zoom capability whereby if the app zooms further than that capability, it would need to manually zoom the preview. However given this behaviour is limited to the nexus 4, it is far easier to just remove the code entirely and disable zoom on the nexus 4 from Gecko as done in bug 983930.
Depends on: 983930
A very minor optimization, but we waste 4-5 ms in the app code (plus any boilerplate in gecko) each time an empty face detection event comes up. This happens around 6 times during app startup. Bug 1215372 has a patch to stop sending these unnecessary events.
Depends on: 1215372
We currently create face views on the critical path. We should defer this until we find actual faces to show rings for and save time up startup. See bug 1215374.
Depends on: 1215374
JS reading and parsing is a significant part of our startup. Any modules we don't need right away should be candidates for lazy loading on demand. See bug 1216556. This should reduce the fully-loaded time significantly.
Depends on: 1216556
Bug 1216598 has been filed against lazy loading taking longer since 2.2 app on 2.2 gecko is faster than 2.2 app on master gecko.
See Also: → 1216598
Use of local cache of device storage available requests in bug 1215644 appears to help draw in the camera fully loaded time in combination with bug 1216556.
Depends on: 1215644
Hi Andrew, I saw camera cold launch was increasing slightly since Aug. The trend is going higher. I think camera doesn't change too much in v2.5. could you help to isolate this issue between Gaia and Gecko? Not sure which part is blocker. Thanks.
Updated numbers from Eli on flame 512MB: https://gist.github.com/eliperelman/b81a27b7f7f3b3f75f49 2.2 visually loaded: 1469.274 ms master visually loaded: 1603.247 ms Looking at the raptor results over the last few weeks, master visually loaded was underestimated and likely 50ms higher in reality.
Thanks Andrew for identifying and working through the perf optimizations for Camera! Todays Raptor results shows visually loaded to be 1.531sec for Flame KK and 751ms on Aries https://raptor.mozilla.org/dashboard/script/measures?var-device=flame-kk&var-memory=512&var-branch=master&var-test=cold-launch 2.2 visually loaded: 1469.274 ms (https://gist.github.com/eliperelman/b81a27b7f7f3b3f75f49) Thanks Hema
Priority: P1 → P2
Unblocking from bug 983930, no need to land this right now as performance is acceptable and this would only be a small gain relatively speaking. It also appears prebuilt nexus 4 images may be provided by us in the future. If we continue to support it, we should fix as much of this as possible in Gecko to hide platform-specific problems.
No longer depends on: 983930
Today's raptor results show visuallyLoaded to be 1483ms for flame which is very close to 2.2. I think we are done here :).
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.