520304 - Improve responsiveness of idle service on mobile platforms.

Status: RESOLVED FIXED

(Core :: Widget, defect)

Description

[Doug Turner (:dougt)]

Attachment: patch v.1

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.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 404361 [details] [diff] [review]
patch v.1

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

static_cast

Comment 2

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/21ca51ccd2a9

Comment 3

[Doug Turner (:dougt)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6bad6421cd2c

Comment 4

[Justin Dolske [:Dolske]]

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...

Comment 5

[Doug Turner (:dougt)]

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?

Comment 6

[Justin Dolske [:Dolske]]

No, it's just AFAIK do_GetService is a relatively costly call, so doing that frequently isn't a great idea.

Comment 7

[Justin Dolske [:Dolske]]

Taras would probably know what the actual cost of that call is.

Comment 8

[Doug Turner (:dougt)]

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.

Comment 9

[(dormant account)]

(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