What are the tradeoffs between performSelector:withObject:afterDelay: and dispatch_after

Question

The only functional difference I have encountered is that I can cancel the message scheduled with performSelector:withObject:afterDelay:. I don't know of a way to cancel a block submitted to dispatch_after. (Please let me know if there is a way to do this that I do not know about).

I'd like to know more about:

• functional tradeoffs (What else can be accomplished with one interface but not the other?)
• performance tradeoffs (Is one implementation more efficient? In which cases?)
• stylistic tradeoffs (Should I prefer one interface for certain tasks to better follow common styles or conventions?)

Answer 1

dispatch_after is part of the new Grand Central Dispatch, which is an extension to iOS aimed at improving concurrent code execution on multicore hardware.

But overall, I think they address different requirements overall. GCD allows to a much finer graded control over concurrent execution of code. You can schedule blocks on a queue, remove them, suspend, resume, etc. It is a broader topic to be considered here in general. Also, GCD provides many more synchronization options.

As far as the comparison with performSelector, I think that one advantage dispatch_after rightly has is the possibility of scheduling a block without the need to define a selector. See this discussion.

On in all, I haven't got much experience with GCD, but I would say that apart from the block scheduling thing, when you simply need to delay some selector execution in your UI, without much a requirement for concurrency in general, I would use performSelector.

If you think about it, performSelector gives you a very poor concurrency, since it simply schedules your selector for execution on the run loop after a minimum amount of time. On the other hand, dispatch_after gives you a control which seems in principle at the level of nanoseconds (!! this is what I get from Apple docs, but I have never used it and I don't think that on an iPhone you would get that, possibly on MacOS).

EDIT: about unscheduling a block, I have never tried to unschedule a block from a queue, but there is a possibility that dispatch_release also allows you to control that. If it does not, you could define your custom queue for the block that you want to cancel and release the whole queue (before the block starts being executed), if that ever makes sense to you.

As to performance, I really don't know what performSelector does inside, but if it schedules a thread, then Apple states that scheduling a block with GCD only costs 15 instructions, while creating a thread costs several hundred of them.

Apart from performSelector, don't forget you have the option of using NSOperationQueue, which is based on GCD, and has some overhead overt it but not that big, they say. NSOperationQueue certainly offers the possibility of cancelling.

Answer 2

Another big advantage of using GCD instead of performSelector is the ability to very simply use multiple local variables as part of the block operation. If you want to defer the execution of a method that takes more than one argument until a later time using performSelector, you have to wrap the arguments you want to use in another object, such as an array. With dispatch_after you can very simply pass any number of local variables to the block. This also applies to non-objects, which you can't pass to a performSelector call without first wrapping in an object, such as an NSValue for passing a CGRect. GCD lets you pass primitives, structs, and objects to the operation you want to defer.