812080 - System Message API: Speed up the .broadcastMessage() for incoming calls

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Gene Lian (I already quit Mozilla)]

Please see Bug 812059, comment #0. Philikon reported we need to take 200ms to broadcast the system messages for incoming calls. I'm wondering if we could have some space to improve that. Currently, .broadcastMessage() is using linear search to decide which page(s) to open, which might be changed to something like hashing.

Let's do some profiling first to see if we could have any chance to optimize this part (or not).

Comment 1

[Gene Lian (I already quit Mozilla)]

Hoping to wait for my Bug 805655 landed for sure (should be soon in a couple of days) and then come back to profile this one, since we're going to have some extra run-time permission checks before sending/broadcasting a system message, which is a must-have check, though.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Doing some little and simple profiling I found that .broadcastMessage() does never take more than 6ms on my machine. However, there seems to be a huge lag before messages are processed which seems to be one of the causes for bug 812115 as well.

Comment 3

[Gene Lian (I already quit Mozilla)]

Benjamin, could you please take this off my overflowing plate. Thanks! :) After V1, we can come back to face these non-bb+ issues.

Comment 4

[Benjamin Chen [:bechen]]

After some simple profile, the SystemMessageInternal.js broadcastMessage method spends almost all the time on |_openAppPage, Services.obs.notifyObservers("system-messages-open-app")|. That means probably we can't improve the response time for a new-incoming-call at this method.

By the way, if dailer is an important process/app, can we treat it as an pre-load process/app? When we boot the phone, we also start dialer app like homescreen.

Comment 5

[Gene Lian (I already quit Mozilla)]

Let's close this one if it's not significant to gain more improvements from .broadcastMessage().