833114 - navigator.mozCameras.getCamera takes between 1300-1800ms ( almost twice hardware initialization time)

Status: RESOLVED DUPLICATE of bug 821841

(Firefox OS Graveyard :: Gaia::Camera, defect)

Description

[James Lal [:lightsofapollo]]

Seems a little high to me... I don't have the background to stay how suspicious this is but we are spending a lot of time in gecko to handle the getCamera.

We should investigate and see where we are spending time outside of hardware initialization.

Comment 1

[Ben Francis [:benfrancis]]

Gabriele has offered to investigate this further, then we can figure out who might be the best person to work on it.

Comment 2

[Gabriele Svelto [:gsvelto]]

I've looked into the issue by applying highly advanced profiling methods (*cough* clock_gettime() *cough*) and from what I can see most of the time is sunk in getting the hardware device handle to the camera and pushing the parameters:

https://mxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraControl.cpp#226

I've timed the Otoro, the Unagi and another device who shalt not be named and the results vary quite a lot between them:

* Otoro

GonkCameraHardware::GetHandle()            ~250ms
nsGonkCameraControl::PushParametersImpl() ~1100ms

* Unagi

GonkCameraHardware::GetHandle()            ~800ms
nsGonkCameraControl::PushParametersImpl()   ~50ms

* Device who shalt not be named

GonkCameraHardware::GetHandle()            ~500ms
nsGonkCameraControl::PushParametersImpl()   ~50ms

The numbers vary quite a bit from time to time, sometimes jumping up by as much as 2-300ms so I've written down those that seemed to come up more consistently, they're not averages. I'll attach a patch with the code I've used for testing this so that you can reproduce my measurements.

Without knowing the code better I would say that there's no way around this unless we can start the process of setting up the camera in parallel with the application launch in the hope that overlap saves us some time.

Comment 3

[Gabriele Svelto [:gsvelto]]

Attachment: Extremely sophisticate profiling code for camera hardware setup overhead

This is the code I used for the measurements, it applies to mozilla-b2g18.

Comment 4

[Mike Habicher [:mikeh] (high bugzilla latency)]

There's another highly advanced :) stopwatch implementation in bug 821841 as well.  That bug also includes a breakdown of what goes on inside GetHandle().

Comment 5

[Gabriele Svelto [:gsvelto]]

(In reply to Mike Habicher [:mikeh] from comment #4)
> There's another highly advanced :) stopwatch implementation in bug 821841 as
> well.  That bug also includes a breakdown of what goes on inside GetHandle().

Actually yours is much better than my ugly hack. I'll discuss it with James and I figure we'll close this bug as duplicate of bug 821841. BTW your patch gave me the idea that it wouldn't be a bad idea if we come up with a fully fledged XPCOM class for stopwatch-like timing as it would help the JS people too. What do you think?

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Gabriele Svelto [:gsvelto] from comment #5)
> 
> BTW your patch
> gave me the idea that it wouldn't be a bad idea if we come up with a fully
> fledged XPCOM class for stopwatch-like timing as it would help the JS people
> too. What do you think?

I think it would be a good idea, as long as it stays relatively lightweight.  No doubt this wheel has been invented before, and will be again.

Comment 7

[Gabriele Svelto [:gsvelto]]

(In reply to Mike Habicher [:mikeh] from comment #6)
> (In reply to Gabriele Svelto [:gsvelto] from comment #5)
> I think it would be a good idea, as long as it stays relatively lightweight.
> No doubt this wheel has been invented before, and will be again.

Yes indeed, I'll give it a bit more thought and open another bug. Closing this as duplicate in the meantime.