Re: Objective-C and Smalltalk; speed of message send

[Leigh Smith]

> Maybe ... I think that most likely the main problem is using stringWithFormat:
> That method is slow for a variety of reasons (it's probably faster now than when the smalltalk test was done),
> not least the fact that it uses the autorelease mechanism.  Autorelease is fundamentally pretty slow, and a
> good garbage collection system would perform better.  However, retain/release/autorelease is the way
> things are currently done.

I'm surprised that automatic garbage collection would be found (or perhaps is just assumed?) to be faster than reference counting. 

>From my own experience developing the MusicKit and SndKit (http://www.musickit.org), reference counting is preferable because it gives us control of when memory is allocated and released, therefore we can ensure these potentially slow operations do not occur with the hard real time constraints of audio signal processing. As an example we can have very efficient signal processing with preemptive scheduling that ensures a single hardware buffer's latency between requesting a sound be played and hearing the result - on Windows, MacOS X and Linux.

More importantly, it's possible to read the code and understand what the hell is going on! Good design is the key (and reference counting does not really compromise that design, in my experience) and the dynamic OO of ObjC aids that design process. Ditto Smalltalk, I certainly wouldn't mind GC, but for real-time work I'd want some control over it, perhaps just hinting impending reuse. Having looked at the audio code of Squeak (not recently), the higher level design is great, but then the connection to the C means big design compromises which miss the opportunity to propagate future design optimisations. 

Of course, this may just suggest we need to look deeper at autorelease to see if caching of releases is possible, but I haven't looked at the GNUstep code, so I don't know if that's appropriate or may already be done.
--
Leigh M. Smith
mailto:leigh@leighsmith.com
http://www.leighsmith.com