I have read a lot about the pros and cons of each , and i know delegates are usually for one listener, and notifications are for many. The question is about performance.
I have read this : NSNotificationCenter vs delegation( using protocols )?
I am sending audio signals from mic, to another class by notification . i know that here i should use the delegate BUT my question is : does delegates will be faster ? because i can see i have some frame rate issue(decreased), and i would like to know if the cause could be the using of notification instead of delegate, or there is no relation ?
Calling the delegate is just a method invocation but when notifications are used there some more stuff should be done behind the scenes to deliver your notification. Considering this - delegate is a bit faster.
Realtime audio processing is a complex task and I tend to think that delegate's method call or sending a notification produces much more less overhead than your audio-processing code.
UPDATE
Considering performance issues you always should do measurements while trying different approaches.
For those interested in performance I ran a simple test in swift using the XCTest framework's
measureBlock
API. The short answer is that if calling in a loop, the difference will be significant.Here is the code used to test:
And the Test Cases:
A Crappy Alternative I Tried
Other considerations are that the performance of NSNotificationCenter obviously may vary based on how many listeners there are for a given event, and the performance of the code executed by those listeners. Its also worth noting that NSNotificationCenter calls the notification listeners synchronously, and on the same thread on which
postNotification
was invoked, which can be a gotcha when first approaching NSNotificationCenter.If you find yourself in a scenario, (as I have) where you need one to many communication, and high performance, you might consider simply implementing an array of delegates. But you need not bother, because the performance of this is actually the worst option.
Delegates come with less overhead and will therefore be executed much faster.
However, in general you should look on performance topics only there where they are likely to be an issue at all. For once-off tasks like sending a notification vs calling a delegate this should never be an issue. But when you plan to perform these in a loop with a variable (depending on data) number of intarations or for a number of data objects where you have fetched or received the data an cannot predict how many there will be - those are the situations where I would consider performance optimization.
Delegates are faster.
Your frame rate issue while recording is not due to delegates or notifications. It is because your are doing all your tasks on the main thread, which also renders the UI.
NotificationCenter is fast enough.
First, I tested the synchronous case of posting and receiving a notification in the main thread, comparing it with a method call on self:
Each number is the worst case among 100 calls.
Since a notification is roughly a tenth of a millisecond slower even in this worst case, it's most likely fast enough, unless you run it in a loop without any other significant computation.
Second, I posted the notification from a background queue and received it in the main queue, comparing it with DispatchQueue:
Here there's almost no difference.
Methodology: - Release mode - iPhone 5s - iOS 10.3.2. - Requests are always handled in the main thread, no matter which thread they're dispatched from.
A delegate will be faster than a notification but neither is necessarily what you need. For audio you should probably measure first. If you need something executed faster before updating the UI then you should look at moving some processing task to another thread via GCD dispatch or NSOperation.