Re: NSNotificationCenter's pointer abuse

[Richard Frith-Macdonald]

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.

> 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.