Monitoring NSNotifications

Question

I noticed in a comment on this post Overhead of NSNotifications , user JustSid says

the overhead won't be noticeable if the App doesn't send out 30+ per run loop cycle

I'd like to write a little helper class that keeps track of how many NSNotifications have been sent on the current run loop cycle and alert me if it's above a certain pre-configurable number. I know I can register for all notifications (pass nil to name and object), but how do I track what run loop cycle they've been sent from?

Answer 1

It would be easy enough to have a category on NSNotificationCenter that increments some internal integer when a notification observer is added (and consequently decrements it when it is removed), but you have to ask yourself: How much is too much?

If you consider it to be some arbitrary integer (say, 30 for example's sake), then what happens when you test it on a device that has more memory and processor constraints than the one you have now? What happens if you test it on a device that can easily handle 30 observers and notifications floating around (it would be a complete waste)? While it would be possible to code general rules, it would be impossible to gauge the impact notifications have on application response time in every case.

The other possibility would be having a background process query the notification stack (or somehow just gauge it internally like above) when the amount of observers brings certain system functions to a crawl. Of course, ignoring the fact that this is way too much work, you'd be designing a sub-system which probably utilizes as much memory and steals as much away from performance as you tried to remedy with it in the first place!

TL;DR There are so many other patterns and structures you could be using instead of notifications, so why are you the one catering to NSNotification's needs?