Blocking IPC message on getting/setting attibutes

[David Bruant]

Hi,

Justin Lebar wrote [1] (it was about the FMRadio API):
> It's true that reading the |frequency| attribute causes a synchronous
> call up to the parent process. But as it turns out, we do a sync
> operation when reading all of the other attributes, as well. The
> parent process does no I/O upon receiving one of these messages.
>
> The issue isn't that a synchronous operation occurs, because that's
> how attributes work, but rather that we wait on a synchronous IPC
> message. This isn't free, but it's a lot cheaper than sync I/O.
>
> Certainly you shouldn't expect getting the frequency (or any of the
> other attributes) to be fast, however.
I wanted to get a feel of how bad this was.
I've tried the following on a Unagi on the remote console (talking to
the main Gaia process I think, not an app) with radio turned on and no
other app running:

function f(){
var radio = navigator.mozFMRadio;
var start = performance.now();
radio.frequency;
var end = performance.now();
console.log((end-start).toFixed(2), 'ms')
}
f()

~0.82ms against ~0.43ms for a normal property access (I did "f.length"
instead of "radio.frequency"). So it's not awful, but there is a
significant difference.
Can anyone tell me if my measurements done in a wrong way (so I'd get
baised results)?
Also, has anyone tried such perf measurements? on other devices?

David

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=779500#c147

[Fabrice Desre]

On 02/21/2013 06:26 AM, David Bruant wrote:
> I wanted to get a feel of how bad this was.
> I've tried the following on a Unagi on the remote console (talking to
> the main Gaia process I think, not an app) with radio turned on and no
> other app running:

So you're in parent process, talking to himself. That's not really a
good way to measure IPC performance. In my experience, a sync IPC call
will take much longer than the 0.4ms difference you are measuring.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[David Bruant]

Le 21/02/2013 19:10, Fabrice Desre a écrit :
> On 02/21/2013 06:26 AM, David Bruant wrote:
>> I wanted to get a feel of how bad this was.
>> I've tried the following on a Unagi on the remote console (talking to
>> the main Gaia process I think, not an app) with radio turned on and no
>> other app running:
> So you're in parent process, talking to himself. That's not really a
> good way to measure IPC performance. In my experience, a sync IPC call
> will take much longer than the 0.4ms difference you are measuring.

I'm trying to create an app [1] that'd use the radio API to measure the
IPC call time on a Unagi and I get this error:
NS_ERROR_FAILURE: Denied @
jar:file:///system/b2g/omni.ja!/components/DOMFMRadioChild.js:56
Any idea where that could come from? I thought the radio API was
available for all apps?
I'm running a rather old build (which I'm still unable to update, but
that's another problem). Build identifier: 20121127132302

Help? :-s

David

[1] https://github.com/DavidBruant/MozApps/tree/gh-pages/RadioBenchApp

[Justin Lebar]

> I'm trying to create an app [1] that'd use the radio API to measure the IPC
> call time on a Unagi and I get this error:
> NS_ERROR_FAILURE: Denied @
> jar:file:///system/b2g/omni.ja!/components/DOMFMRadioChild.js:56
> Any idea where that could come from? I thought the radio API was available
> for all apps?

See dom/apps/src/PermissionsTable.jsm -- the FM radio is marked as
being available to all apps.

> I'm running a rather old build (which I'm still unable to update, but that's
> another problem). Build identifier: 20121127132302

Ouch, that is a very old build.

[David Bruant]

Le 22/02/2013 17:43, Justin Lebar a écrit :
>> I'm trying to create an app [1] that'd use the radio API to measure the IPC
>> call time on a Unagi and I get this error:
>> NS_ERROR_FAILURE: Denied @
>> jar:file:///system/b2g/omni.ja!/components/DOMFMRadioChild.js:56
>> Any idea where that could come from? I thought the radio API was available
>> for all apps?
> See dom/apps/src/PermissionsTable.jsm -- the FM radio is marked as
> being available to all apps.

Yes. Apparently I need to put "fmradio" in the manifest even when the
API is available to all apps. I assumed I wouldn't.

>> I'm running a rather old build (which I'm still unable to update, but that's
>> another problem). Build identifier: 20121127132302
> Ouch, that is a very old build.

:-) As I said, I'm unable to update it. I'll work on that at some point.
For now, it does what I need from it.

David

[David Bruant]

Le 21/02/2013 19:10, Fabrice Desre a écrit :
> On 02/21/2013 06:26 AM, David Bruant wrote:
>> I wanted to get a feel of how bad this was.
>> I've tried the following on a Unagi on the remote console (talking to
>> the main Gaia process I think, not an app) with radio turned on and no
>> other app running:
> So you're in parent process, talking to himself. That's not really a
> good way to measure IPC performance. In my experience, a sync IPC call
> will take much longer than the 0.4ms difference you are measuring.

I've made an app [1] and launched it as remote.
I've tapped about ~30 times (taping measures how long it takes to get
the value). I observe ~4.5ms usually. If the values hasn't been
requested for a while, it can be 5-9ms. I've seen that once it took 10ms
and once 109ms (!).

David

[1] https://github.com/DavidBruant/MozApps/tree/gh-pages/RadioBenchApp