[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSNotificationCenter's pointer abuse
From: |
Richard Frith-Macdonald |
Subject: |
Re: NSNotificationCenter's pointer abuse |
Date: |
Mon, 13 May 2013 09:05:46 +0100 |
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.