Closed Bug 520304 Opened 11 years ago Closed 11 years ago

Improve responsiveness of idle service on mobile platforms.

Categories

(Core :: Widget, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: dougt, Assigned: dougt)

References

Details

Attachments

(1 file)

Attached patch patch v.1Splinter Review
mobile platforms (windows ce, windows mobile, linux) idle service returns how long the application has been idle.  The current implementation checks for a timestamp variable that is updated in the nsWindow.  The problem is that we check no more than every 5 seconds to see if the application is busy.  So, on average it take 2.5 seconds before we broadcast the "back" event.

On systems where we are telling the idle service that we are active, we can improve on this by directly letting the service know when we change the underlying idle value.
Attachment #404361 - Flags: review?(vladimir)
Attachment #404361 - Flags: review?(vladimir) → review?(bugmail)
Attachment #404361 - Flags: review?(bugmail) → review?(roc)
Comment on attachment 404361 [details] [diff] [review]
patch v.1

+  nsIdleService* is = (nsIdleService*) idleService.get();

static_cast
Attachment #404361 - Flags: review?(roc) → review+
http://hg.mozilla.org/mozilla-central/rev/21ca51ccd2a9
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Attachment #404361 - Flags: approval1.9.2?
Attachment #404361 - Flags: approval1.9.2? → approval1.9.2+
You're... calling do_GetService() for every event?! And assuming that you can .get() and cast to nsIdleService? That seems really bad.

There's a do_GetService(const nsCID& aCID) flavor that I think would at least help with the latter...
performance --- not sure if matters; do you see perf problems with this approach?  Also, the idle service is implemented in widget.  I suppose I could just hang a global variable to the singleton and reach for it in the widget code, but is it worth it?
No, it's just AFAIK do_GetService is a relatively costly call, so doing that frequently isn't a great idea.
Taras would probably know what the actual cost of that call is.
gs is a lock and a hashtable lookup last I checked.  Given no contention on the lock (since we are idle), i can't imagine this being too bad.  

I thought you were worry, I suppose, if anything, if someone decided to reimplement the idle service outside of gecko, we could crash and die horribly.  but really, you shouldn't need to do that.
(In reply to comment #7)
> Taras would probably know what the actual cost of that call is.

I think it's < 0.1ms, but in the longer nearterm we'll be getting rid of such calls as part of bug 516085
Depends on: 520933
You need to log in before you can comment on or make changes to this bug.