Re: NSTimer or what?

[Gerriet M. Denkmann]

> On 20 Jun 2017, at 16:24, Alastair Houghton  
> wrote:
> 
> On 20 Jun 2017, at 04:04, Gerriet M. Denkmann  wrote:
>> 
> 
>> 2. some other thing repeatedly about every 0.1 second.
> 
> Personally, I’d choose an API that directly supports repeating timers, so I’d 
> prefer NSTimer or CFRunLoopTimer over the other options, all else being 
> equal. 

I have just tested dispatch_after() versus NSTimer and it turns out that you 
were right: NSTimer is the better choice.

The dispatch_after version takes about 6 % more Cpu time, compared to the 
NSTimer version.
Also the NSTimer version takes less code. Better on both counts.

Kind regards,

Gerriet.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Re: NSTimer or what?

[Gerriet M. Denkmann]

> On 20 Jun 2017, at 16:24, Alastair Houghton  
> wrote:
> 
> On 20 Jun 2017, at 04:04, Gerriet M. Denkmann  wrote:
>> 
>> macOS 11+
>> 
>> Some Cocoa app which has to do:
>> 1. something a few seconds later
> 
> The main issue here isn’t energy use so much as whether you want to be able 
> to cancel the operation.  If you need to be able to cancel it before it 
> fires, you’ll want to use NSTimer or a CFRunLoopTimer.

I indeed need the things to cancel: The app might schedule a thing to be done 
in 5 seconds, then decides after 2 seconds that something else has to be done: 
so it need to cancel the previous thing.

[NSTimer invalidate] - very simple.

I tried dispatch_after, where the block checks whether it is cancelled before 
starting. Works fine. Not the most elegant code though.

I did not try these two solutions, but they seem to be cancellable as well:
NSRunLoop   performSelector:target:argument:order:modes:
cancelPerformSelector:target:argument:

NSObjectperformSelector:withObject:afterDelay:
cancelPreviousPerformRequestsWithTarget:selector:object:


>  Energy wise, the fact this is to happen “a few seconds later” would seem to 
> imply that it isn’t going to happen often, so it’s probably irrelevant and 
> which you choose is a matter of taste.

A valid point. Probably NSTimer is the most elegant solution here.

> 
>> 2. some other thing repeatedly about every 0.1 second.
> 
> Personally, I’d choose an API that directly supports repeating timers, so I’d 
> prefer NSTimer or CFRunLoopTimer over the other options, all else being 
> equal.  I’d imagine that’s most likely to result in the lowest energy usage 
> (repeated use of one-shot timers, it seems to me, is much more likely to 
> result in dynamic memory allocation happening every time the timer fires, and 
> it’s more complicated in your code because you’ll have to manage your next 
> fire time).

I’ll try NSTimer here too and compare the results.

Kind regards,

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Re: NSTimer or what?

[Alastair Houghton]

On 20 Jun 2017, at 04:04, Gerriet M. Denkmann  wrote:
> 
> macOS 11+
> 
> Some Cocoa app which has to do:
> 1. something a few seconds later

The main issue here isn’t energy use so much as whether you want to be able to 
cancel the operation.  If you need to be able to cancel it before it fires, 
you’ll want to use NSTimer or a CFRunLoopTimer.  Energy wise, the fact this is 
to happen “a few seconds later” would seem to imply that it isn’t going to 
happen often, so it’s probably irrelevant and which you choose is a matter of 
taste.

> 2. some other thing repeatedly about every 0.1 second.

Personally, I’d choose an API that directly supports repeating timers, so I’d 
prefer NSTimer or CFRunLoopTimer over the other options, all else being equal.  
I’d imagine that’s most likely to result in the lowest energy usage (repeated 
use of one-shot timers, it seems to me, is much more likely to result in 
dynamic memory allocation happening every time the timer fires, and it’s more 
complicated in your code because you’ll have to manage your next fire time).

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Re: NSTimer or what?

[Quincey Morris]

On Jun 19, 2017, at 20:04 , Gerriet M. Denkmann  wrote:
> 
> What is the most efficient (energy-wise) way to do this:
> 
> NSTimer (with tolerance)
> NSRunLoop performSelector:target:argument:order:modes:
> NSObject  performSelector:withObject:afterDelay:
> GCD   dispatch_after

I don’t think it really matters, compared to waste of energy that polling for 
an extended period (with a timer) implies. The tolerance isn’t going to help 
you here, because it’s for coalescing things that (say) happen when the display 
wakes or radios turn on or network interfaces activate — things that take 
longer than 0.1 seconds to finish, usually.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com