Re: Observing Time
Re: Observing Time
- Subject: Re: Observing Time
- From: Steve Sisak <email@hidden>
- Date: Fri, 26 Jul 2013 12:23:19 -0400
At 12:36 AM +0900 7/27/13, email@hidden wrote:
On 2013/07/27, at 0:26, Scott Ribe <email@hidden> wrote:
On Jul 26, 2013, at 8:13 AM, Steve Sisak <email@hidden> wrote:
It's worth noting that's very energy inefficient.
Once the WWDC sessions are back on line, watch
the energy efficiency sessions to see what's
happening with timers in Mavericks.
Good point. Though this timer is pretty little and the app wouldn't
be doing a lot else.
But it stands to reason that it could be battery friendly to suspend
it when the app is not visible. And to offer a battery power pref to
suspend when it's not the front application.
(Without going into any system-specific details)
One of the biggest ways that current-generation processors conserve
power is to power down parts of the chip that aren't currently in
use, however the act of powering up and down takes time and wastes
power.
If you have lots of timers going off, the OS still has to wake up the
CPU to service the timer -- even if it's got nothing to do.
A savvy OS could conserve power by grouping timers together, so
they're all handled during a single "wake-up" -- that saves all the
power (and time) wasted in waking and sleeping parts of the CPU. It
also increases the jitter in the timers.
By giving the OS good information on what you're trying to do, you
give it flexibility to balance conserving power and provide accurate
timing.
-------------
BTW, from the NSTimer reference:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/Reference/NSTimer.html
A repeating timer always schedules itself based on the scheduled
firing time, as opposed to the actual firing time. For example, if a
timer is scheduled to fire at a particular time and every 5 seconds
after that, the scheduled firing time will always fall on the
original 5 second time intervals, even if the actual firing time
gets delayed. If the firing time is delayed so far that it passes
one or more of the scheduled firing times, the timer is fired only
once for that time period; the timer is then rescheduled, after
firing, for the next scheduled firing time in the future.
This means you ought to be able to set up a repeating 1 second timer
with an initial delay calculated to make it go off at the "top of the
second".
With any luck, you'll get serviced on the same wake-up as the menu bar clock.
In your case, a little jitter is only cosmetic -- if you do wander,
it's because the CPU was busy. You also might want to check in your
callback to see if you're too far off and reschedule if needed. Don't
forget that timers get suspended during sleep.
If you're stuck, I could probably figure out how to do the same thing
with Mach time.
HTH,
-Steve
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden