On 10 May 2013, at 12:23, Richard Frith-Macdonald <[email protected]> wrote:
> > On 10 May 2013, at 11:56, David Chisnall <[email protected]> wrote: > >> On 9 May 2013, at 00:52, Richard Frith-Macdonald >> <[email protected]> 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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
