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. > 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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
