Re: NSNotificationCenter's pointer abuse

[Richard Frith-Macdonald]

On 10 May 2013, at 12:23, Richard Frith-Macdonald <address@hidden> wrote:

> 
> On 10 May 2013, at 11:56, David Chisnall <address@hidden> wrote:
> 
>> On 9 May 2013, at 00:52, Richard Frith-Macdonald <address@hidden> wrote:
>> 
>>>> If GSIMap wont let us mix different usages in on file
>>> 
>>> That's a big IF...
>> 
>> The extra conditional code appears to be a work around for GSIMap only being 
>> able to be used once per compilation unit.  I don't know if this is actually 
>> the case,
> 
> I already pointed out that it obviously isn't  .... because the macro has the 
> map as a parameter and can therefore be written to treat different maps 
> differently (as indeed it does for NSMapTable).
> Though it may have been the case at the point when the code was originally 
> written.

I changed that  ... three lines of code changed (or seven I think,  if you 
include removing the comment).

>> but I don't think I've ever seen a file that includes GSIMap.h more than 
>> once per file.
>> 
>> This file also appears to reimplement a lot of things that are implemented 
>> elsewhere, and contains a lot of optimisation.  It's not clear how much the 
>> optimisation actually speeds things up (the IMP caching that it does will 
>> give a small speedup, but actually breaks the semantics of the notification 
>> center - see the test case I committed yesterday, which passes on OS X but 
>> fails on GNUstep).  It's also not clear how applicable it is to modern 
>> systems.  The memory pool, for example, is unlikely to give a noticeable 
>> speedup relative to a modern malloc() and will increase both memory usage 
>> and fragmentation.
>> 
>> I've started doing a naïve implementation of NSNotificationCenter, which I'd 
>> like to compare to the existing one for memory usage and performance.  If 
>> anyone has any code that makes heavy use of notifications, please let me 
>> know.
> 
> Unfortunately I don't have any now ... it's a long time since this stuff was 
> written.
> The current notification code was extensively benchmarked when it was written 
> (in response to reports of poor performance reelative to OSX) ... and 
> performed very much faster than the original implementation (multiples of the 
> speed) and several percent faster than the OSX implementation at the time.
> It may well be that on modern systems some optimisations are unnecessary and 
> can now be removed.
> 
> Don't waste your time on a 'naive' implementation without getting good, 
> thorough benchmarking first (both with clang/libobjc2 and the traditional 
> runtime).
> It is utterly trivial (probably a one line code change) to disable the IMP 
> caching and see how that effects benchmarks ... so you could try doing that 
> first.

I also removed the method caching ...  it was, as I thought, only a one line 
change to disable it. But since we are trying to mimic OSX behavior exactly, I 
thought we probably ought to remove it anyway.

As I recall this particular optimisation was really pretty irrelevant for most 
apps (it made a significant performance difference to some apps where the same 
notification was fired really frequently, but wasn't a show-stopper).
One thing I recall finding out when the notification code was rewritten was 
that different people use notifications in radically different ways.
Some generate vast numbers of notifications, to a few observers, some generate 
few notification but to lots of observers, and some actually add and remove 
observers much more often than they deal with notifications, or remove/add 
observers after each notification.