At 12:36 AM +0900 7/27/13, [email protected] wrote:
On 2013/07/27, at 0:26, Scott Ribe <[email protected]> wrote:

 On Jul 26, 2013, at 8:13 AM, Steve Sisak <[email protected]> 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 protected])

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to